| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The inner type is an eyesore, and doesn't really need to be exposed
outside of tor-proto (we might even replace it at some point).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need it anymore now that `RelayCirc`s always allow incoming
stream requests.
The previous design, where you could build a `RelayCirc` that didn't
allow stream requests, was a leftover from the onion service
`ClientCirc` implementation that this was inspired from (onion services
*do* need the two to be decoupled, because incoming stream requests are
only allowed on the virtual hop, after it's established).
Closes #2582
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements what we discussed in
`doc/dev/notes/relay-streams.md` (lines 218-234):
> Currently, to allow incoming stream requests on a circuit,
> you first need to call `RelayCirc::allow_stream_requests()`
> to install a `CmdChecker` and `IncomingStreamRequestFilter`.
> This is not ideal, because `allow_stream_requests()` will need to be
> called unconditionally, on each `RelayCirc`,
> right after it's created in the `CreateHandler` impl
> (which in turn, would mean making `handle_create()` async too,
> because `allow_stream_requests()` is async, which wouldn't be great).
>
> So, the first step here is to rework the `RelayCirc` API to make relay circuits
> be constructable with a list of allowed `RelayCmd`s and `IncomingStreamRequestFilter`
> from the get-go ([#2582]), and to get rid of `allow_stream_requests()`,
> which will enable the `CREATE*` handler to remain non-`async`.
>
> In any case, the `CREATE*` handler will still require some changes,
> because it needs to be initialized with an `IncomingStreamRequestFilter`,
I am not sure using an `IncomingStreamRequestFilter` "factory" is
necessarily the right approach here, but the circuit `Reactor`'s
constructor needs to take an `IncomingStreamRequestFilter`, and
`IncomingStreamRequestFilter` is not `Clone` (and FWIW, I think it's
better if we don't make it `Clone`).
One obvious limitation is that the `IncomingStreamRequestFilter` of the
circuit reactor is fixed for the entire lifetime of the circuit.
In practice, I don't think this is going to be a problem,
because the arti-relay `IncomingStreamRequestFilter` is only going
be used for
* preventing single-hop exit streams
* per-circuit rate-limiting.
Both of these checks will require the filter to have access to a recent
`NetDir`, which is straightforward if the filter has an Arc<dyn
NetDirProvider> (as mentioned in doc/dev/notes/relay-streams.md,
`NetDirProvider` has a handy non-async `timely_netdir()` function we can
use). And since these checks are based on consensus params, we don't
really need to ever update an already-built circuit with a new
`IncomingStreamRequestFilter` (because all `IncomingStreamRequestFilter`
will have the ability to obtain a fresh `NetDir` as needed).
Nevertheless, I left a TODO about this, because I expect this type to
change once we figure out all the other pieces needed for #1448.
|
| |
|
|
| |
Closes #2590
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17.
Reverted because we no longer need to "peek" into the opaque
`CircChanMsg` of a circuit reactor: now the implementation-dependent
part of the reactor is in charge of handling the channel messages,
and extracting `Relay` objects out of RELAY/RELAY_EARLY cells,
which then get processed in the base reactor.
|
| |
|
|
|
| |
This type is needed in the tor-chanmgr crate in order to decide to
verify or not the underlying relay channel.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This will be used in a future commit, inside the new generic circuit
reactor.
We need it because RELAY cells are handled very similarly, so we need
some way of finding out if a given generic chancell is actually a RELAY
cell that we can handle in an implementation-agnostic way.
|
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
This follows the move of the client specific object.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
This will be needed soon.
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| |
|
|
| |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| |
|
|
|
|
|
| |
This implements the relay initiator side of the handshake up to the
creation of an unverified channel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
|
|
This reorganizes the `relay_tunnel` module as per @dgoulet's
[suggestion].
[suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
|
