| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
| |
This will enable us to obtain implementation-dependent asynchronous
events (such as the outcome of an extend handshake).
|
| |
|
|
|
|
| |
This will be needed by relays, for wrapping tor_linkspec decode errors
(which can happen if the link specifiers in the EXTEND2 cell can't be
converted to a channel target).
|
| |
|
|
| |
To match the `ChannelProvider::get_or_launch()` function signature.
|
| |
|
|
|
|
| |
We need the unique_id here, because the Forward handler will soon start
using the `ChannelProvider::get_or_launch()` to launch outbound
channels, which takes the reactor unique_id as an argument.
|
| |
|
|
|
|
| |
The channel provider is relay-specific, so I am moving it to the relay
`ForwardHandler` implementation. This enables us to get rid of some of
the feature gating from the generic reactor.
|
| |
|
|
| |
This is currently very similar to its client counterpart.
|
| |
|
|
| |
We will need the ability to build one from within tor-proto.
|
| |
|
|
| |
Needed for handling the linkspecs in an EXTEND2 cell.
|
| |
|
|
| |
This was leftover from back when this command was only for Sendmes.
|
| |
|
|
| |
This just removes an unnecessary `async`.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
Remove the use of traits, the caller will handle the specific type.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
No need for these types, we've replaced them with more specific types.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Add the unverified, verified, non verifiable flavor types of a responder
channel.
This follow on the previous commit to use the type system for stronger
guarantees.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the Unverified and Verified flavor of a relay channel
specific to an initiator.
We decided to use the type system for safety and avoid patterns like:
"if chan.is_initiator() {...} else {...}"
This allows us also to not duplicate code between initiator and
responder code.
The downside is that we expose these types outside of tor-proto meaning
the caller needs to feature gate the usage of these types with the
"relay" flag.
Small price to pay for strong guarantees with the type system.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
itself
Previous function "build_auth_data()" is still around but will be
removed in the upcoming commits.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This was leftover from back when the BWD was a relay-specific type.
|
| | |
|
| |
|
|
|
| |
This will soon be used for instructing the BWD to send other types of
messages too.
|
| |
|
|
|
|
|
| |
The backward reactor will soon need the ability to send other types of
relay messages too: it will soon need the ability to respond to EXTEND2
by sending back an EXTENDED2, so I am preemptively making this function
more general so we can reuse it.
|
| | |
|
| |
|
|
| |
Since we removes a existing feature, we need to bump the version.
|
| |
|
|
|
|
|
|
|
|
| |
Done via:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.39.0
done
```
|
| |
|
|
| |
This will need to become async soon.
|
| |
|
|
| |
Fixes a clippy warning
|
| | |
|
| |
|
|
|
|
|
| |
In the backward reactor, we call this the `forward_reactor_rx` (because
it receives commands from the foward reactor), and in the forward
reactor we call it `backward_reactor_tx` (because it sends commands to
the backward reactor).
|
| |
|
|
|
|
|
|
|
|
| |
We settled on
* `inbound_chan{tx, rx}`, for the inbound channel (the channel towards
the guard, if we are a client, or towards the client if we are a
relay)
* `outbound_chan{tx, rx}`, for the outbound channel (the channel
towards the exit, if we are a middle relay)
|
| | |
|
| |
|
|
|
| |
This will change significantly in the near future, or disappear
entirely.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This is just because the generic reactor will soon need a clone of the
CC object, so I am preemptively making this function return a ref to the
underlying `Arc` instead. Technically, it would've been fine to just
kept this method and add a separate one returning `&Arc<Mutex<..>>`,
but I'd prefer keeping the API small.
|
| |
|
|
|
| |
This renaming is needed because I will soon introduce a new `Forward`
struct, with a completely different purpose.
|
| |
|
|
|
|
| |
Soon it won't need be needed here any more. I'm removing it, because
having redundant handles to the CC state makes it difficult to see
exactly where it's being used from.
|
| |
|
|
| |
This is not just for clients!
|
| |
|
|
| |
Currently empty, will be fleshed out in a future commit.
|
| |
|
|
| |
I am about to use this in other places too.
|
| | |
|
| |
|
|
| |
Relays will need to use it too.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This will be used in the stream reactor too (and the stream reactor will
eventually replace the corresponding client impl).
|
| |\
| |
| |
| |
| |
| |
| | |
maint/add_warning: Deny clippy::unused_async
Closes #2328
See merge request tpo/core/arti!3613
|
| | | |
|
| | |
| |
| |
| | |
This code is still WIP, so I propose we ignore the lint for now.
|
| | |
| |
| |
| |
| | |
This resolves a warning triggered by the newly-introduced
`#[deny(clippy::unused_async)]`.
|
| | |
| |
| |
| | |
This adds the lint to all our crates.
|
| |\ \
| |/
|/|
| |
| | |
clippy: Fix missing doc for non-Linux builds
See merge request tpo/core/arti!3611
|
| | | |
|