| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
This is not a MUST for client-side conflux, so I'm filing it as tech
debt.
|
| | |
|
| |
|
|
|
|
| |
We don't have a way to compare virtual hops (see #2016), and we don't
yet support onion service conflux (see #2002), so let's defer this for
now.
|
| |
|
|
| |
This is tech debt, and is not a MUST for conflux.
|
| |
|
|
|
| |
We can tackle this later, after we finish addressing all the remaining
`TODO(conflux)`.
|
| |\
| |
| |
| |
| | |
tor-proto: use the visibility crate for benchmarks
See merge request tpo/core/arti!3010
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
