| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
(This is a bit trickier than I would like, but it ensures that we
never return a "not initialized yet" code.)
|
| |
|
|
|
|
|
| |
We'll need this for our rpc-library code to meaningfully open SOCKS
connections.
Closes #1523.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |
|
|
| |
The context will make it possible to invoke rpc methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that Rust won't let us say
```
type ConnTarget<R> = Arc<dyn ClientConnectionTarget>;
```
because the R parameter wasn't used.
Previously we solved this by using a macro instead of a type
definition, which is ugly.
I had been thinking previously I would need to declare some kind of
additional wrapper type, and had shrunk from the verbosity. But
@diziet pointed out that I could just use a 2-tuple unconditionally.
It's still not beautiful, but it is less hideous than before.
|
| |
|
|
| |
(This is a separate commit to make the branch more readable)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |
|
|
|
|
|
|
| |
These have been subsumed by other errorkinds, mostly
OnionServiceProtocolViolation and TorProtocolViolation.
In particular please review the change in tor-hsclient closely;
I am not sure about the new errorkinds for the error there.
|
| |
|
|
|
|
|
|
|
| |
This takes an approach discussed in #736: Instead of trying to
distinguish INTRO/REND failures perfectly, we instead map our
existing ErrorKinds as best we can, in respect to the fact that
this distinction is not super important in practice.
Closes #736
|
| |
|
|
| |
Use this to emit HS_BAD_ADDRESS as appropriate.
|
| |
|
|
|
| |
These errors are orthogonal to our actual error kinds. See
discussion on #736.
|
| |
|
|
| |
Part of #736
|
| | |
|
| |
|
|
|
|
|
| |
We don't yet return all of them; this commit adds some todo notes
about changes we may need to our ErrorKinds.
Part of #736
|
| | |
|
| |
|
|
| |
Fixes `cargo check`
|
| |
|
|
|
|
|
|
|
| |
The actual decoding here is just a placeholder. The important part
is that we can get either a (SessionId, StreamId) tuple out of the
request, or we treat it as part of an isolation token.
This commit has a few TODOs for additional things that we'll need
in order to build out our design.
|
| | |
|
| |
|
|
| |
This enables some small simplifications.
|
| |
|
|
|
| |
It will use this to find which TorClient to use when opening a
stream.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, there was a bug in the way that our code used our SOCKS
implementations. If the buffer used for a SOCKS handshake became full
without completing the handshake, then rather than expanding the buffer
or closing the connection, our code would keep trying to read into the
zero-byte slice available in the full buffer forever, in a tight loop.
We're classifying this as a LOW-severity issue, since it is only
exploitable by pluggable transports (which are trusted) and by
local applications with access to the SOCKS port.
Closes #861.
Fixes TROVE-2023-001.
Reported-By: Jakob Lell <jakob AT srlabs DOT de>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Retain "SocksHandshake" as a deprecated synonym.
Also, make an (on-by-default) feature for SocksProxyHandshake.
(There is about to be a SocksClientHandshake as well.)
|
| |
|
|
|
| |
Also, note why we aren't hiding the addrs that we're listening on
here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The remaining unconditionally public APIs are those related to our
configuration objects, and the main_main() API.
The rationale for making main_main() public is to have an actual
entry point.
The rationale for making the config APIs public is:
1. We really do intend for others to be able to read our
configuration files using this API.
2. The structure of our configuration files is already part of our
interface.
Closes #530.
|
| |
|
|
| |
Also, make private a function that had formerly been `pub`.
|
| | |
|
| |
|
|
|
| |
This specifically applies the `sensitive` wrapper in the places
where we're logging target addresses at level "info" or higher.
|
| |
|
|
|
| |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring a `Box<dyn Isolation>`, it now takes either a
`Box<dyn Isolation>`, or an arbitrary `T` that implements
`Isolation`.
This API still allows the user to pass in a `Box<dyn Isolation>` if
that's what they have, but it doesn't require them to Box the
isolation on their own.
Part of #414.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
