| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The [latest version] of `cargo-sort` is more opinionated than the
previous one, and is now causing the `rust-checks` job to fail on
`main`.
This commit applies the fixes needed to satisfy the new `cargo-sort`
rules. These changes were generated by running `cargo sort --workspace`
several times, until `cargo sort --check --workspace` finally succeeded
(it couldn't fix all the errors in one go, for some reason).
I have omitted the changes `cargo-sort` made to the top-level
`Cargo.toml`, to preserve the topological ordering of the workspace
members.
Closes #2014
[latest version]: https://github.com/DevinR528/cargo-sort/blob/f066ae80e5e6f5c1d8f0e2b8099461dcb97d9656/changelog.md#200
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: Prevent sink and rx from being dropped in-place.
Closes #2005
See merge request tpo/core/arti!3005
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This was supposed to be fixed in 164d6b4d6c5, but that change failed to
bind `sink` and `rx in `futures::join!`, causing `sink` and `rx` to get
dropped, which would, in turn, cause the channel and circuit reactors to
shut down, sometimes leading to intermittent failures (#2005).
Closes #2005
|
| | | |
|
| | |
| |
| |
| | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3002#note_3200935
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit c2d9ea952b4dcb91d05ee754e8d1a6ec6a0689b2.
`QueryLegs` is now unused. We also decided we won't need it for
implementing `Tunnel::path_ref()` as we are keeping the
`MutableState` between `ClientCirc` and the reactor (see !2996).
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, `ClientCirc:allow_stream_requests()` would return an error
when called on a multi-path tunnel.
My main reason for removing the conflux set length check is because it
enables us to remove the `QueryLegs` control command (which is something
we were planning on doing anyway).
Note that now that we've removed `ClientCirc::legs(), there's no way for
a multi-path `ClientCirc` to access its circuit legs, but that is fine,
because it's currently impossible to build multi-path `ClientCirc`s in
arti anyway. This issue will be addressed in the fork, in the new
`ClientTunnel` type that will be used for multi-path tunnels (a
`ClientCirc` will only ever be single-path, so it won't need to have a
`legs()` function at all).
I am also removing the `TODO(conflux)` that justifies the now-removed
check, because it's outdated (nowadays the `CellHandlers` are shared
between the tunnel reactor and its circuits). That said, we *still*
don't support onion service conflux, but that will be tackled separately
because there are a bunch of issues that still need to be resolved to
make it work (which I'll document separately).
Note that I've also made some changes to pass the `LegId` of the circuit
that received the incoming stream request to `StreamReqInfo` and
`StreamTarget`. This is in preparation for supporting multipath onion
service conflux, and because the `HopLocation` from `StreamTarget`
*needs* a `LegId`.
|
| | |
|
| |
|
|
|
| |
These `TunnelMutableState` impls just delegate to `MutableState`, so we
might as well link to the corresponding docs.
|
| | |
|
| | |
|
| |
|
|
| |
Hiding the underlying type makes the code less readable.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become
fallible (we can't unwrap the result, because when a circuit is closed,
its state gets removed from the `TunnelSharedState`, but its
`ClientCirc` handle continues to exist, so any attempt to retrieve the
state will result in an `Err`).
|
| |
|
|
|
|
|
|
|
|
| |
We now have a new `TunnelSharedState` type for storing the shared state
of a tunnel. It consists of the `MutableState`s of all the circuits in
the tunnel, which are shared between it and `Circuit` (the circuit
subcomponent of the reactor). The `TunnelSharedState` itself is shared
between `ConfluxSet` (which manages the `Circuits`), and `ClientCirc`
(the reactor handle used to access information about circuits, such as
their `Path`).
|
| |
|
|
| |
This will simplify some callsites.
|
| |
|
|
|
| |
Not locking the `MutableState` mutex outside of this impl makes it
easier to see it's currently impossible deadlock.
|
| |
|
|
|
|
| |
This renaming is in preparation for the addition of a newtype wrapper
for what used to be `Mutex<MutableState>`. That newtype wrapper will be
called `MutableState`.
|
| | |
|
| |
|
|
|
|
| |
These functions have been deprecated for a while, and are now
complicating the `MutableState` changes we need to do for #1840, so it
seems like a good time to remove them.
|
| |\
| |
| |
| |
| | |
tor-proto: change bench measurement
See merge request tpo/core/arti!2998
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
These were generated with an updated version of the python reference
implementation.
|
| |
|
|
| |
See torspec#332.
|
| |
|
|
| |
Implements part of proposal 358.
|
| |
|
|
| |
This required some renaming, so that the types and their codes matched.
|
| |
|
|
|
|
|
| |
This type will, because of prop358, be shared by ntorv3,
hs-ntor, and probably other future handshakes.
There will also be a CircResponseExt type.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now instead of using CryptState for everything, we have specific
types for each role and direction of crypto.
This turned up a harmless-so-far bug in our onion service code: as
an onion service, we were using _client_ crypto layers to respond to
a client request. That's not correct, and wouldn't have worked
with CGO. Instead, we need to use relay crypto layers, wrapped
as client layers.
Closes #1975.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the trait was to parameterize the tor1 cell crypto
on the different possible relay cell layouts.
It made sense to have this trait when we thought we would implement
the new cell layout for prop340 (packed-and-fragmented) well before
we implemented CGO.
But it now appears all but certain that CGO will land long before
we make any more headway on prop340. Therefore,
it doesn't make sense to carry the ability to customize `tor1`
for other relay cell layouts.
Removing this trait saves a fair bit of complexity.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the code to copy a SendmeTag rather than returning a
slice. This isn't actually a big change: sending a slice already
required 16 bytes (on 64-bit platforms), so sending a SendmeTag
around isn't a big deal.
We rely extensively on the compiler's ability to optimize away
all the checking in code like this:
```
let slice: &[u8];
let a: [u8;N] = slice[0..N].try_into().expect("Nope");
```
I've spot-checked it somewhat with "cargo-show-asm", but
it could use more thorough checking.
Closes #1956.
|
| | |
|
| |
|
|
|
| |
This doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
|
| |
|
|
|
|
| |
This lets us use `Aes128Dec` and `Aes128Enc` in place of plain old
`Aes128`, which can be less space-efficient depending on the
back-end.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: New extend() and create_firsthop() to pick between ntor and ntor3
Closes #1970
See merge request tpo/core/arti!2967
|
| | |
| |
| |
| |
| |
| | |
Since we have create_firsthop() and extend(),
we should recommend them in our documentation,
instead of recommending the no-longer-best methods.
|
| | | |
|
