| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
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.
|
| |
|
|
| |
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
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
arti: Downgrade "stream closed without END" warning to debug.
Closes #2304
See merge request tpo/core/arti!3608
|
| | |
| |
| | |
Co-authored-by: carti-it <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As near as I can tell, there are only three ways that the sender
corresponding to this rx can be dropped:
- `StreamMap::terminate` because the stream object itself was
dropped. (But see #2323.)
- `StreamMap::close_stream` because an END message or similar
has been received. (But see #2322.)
- The `StreamMap` has been dropped.
The first two cases are already handled, and AFAICT the third can
only happen when the circuit hop closes. That makes
`CircuitClosed` the appropriate error here, not `StreamProto`.
Part of a fix for #2304.
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This commits returns either Some(AUTH_CELL, CERTS) or None. We future
proof ourselves against one Some and other None even if an error check
is done before.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the channel type from Unverified and Verified channels and
instead use the channel type in the underlying channel codec.
The codec requires such type in order to restrict messages sets. Instead
of duplicating it, this commit simply makes it that there is now only a
single channel type attached to a channel structure.
The resulting `struct Channel` in the end gets it copied from the
channel codec as the framed_tls gets split and given to the `Reactor`.
Down the line, we need a channel type attached to the `Channel` in order
to know if it is a client or not and authenticated or not.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
Avoid having one None and the other Some which would be a bug.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
Instead, use the static AUTHTYPE_ED25519_SHA256_RFC5705 value which is
for now the only version we support.
Signed-off-by: David Goulet <[email protected]>
|