| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |\
| |
| |
| |
| | |
Enable counter-galois onion negotiation and make it work.
See merge request tpo/core/arti!3133
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This change fixes a CGO bug: when extending circuits with ntorv3,
we were never actually using CGO encryption for the newly
constructed layer.
This change also simplifies the code a bit, by un-parameterizing
CircuitExtender a bit.
|
| | | |
|
| | |
| |
| |
| | |
Now that we can negotiate CC, we can negotiate CGO.
|
| | |
| |
| |
| |
| | |
We're not sure why `cargo fix` did this, but it doesn't seem
necessary.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The two main causes of errors were:
- Since some of the lifetime rules have changed, we no longer need
to do as many "bind a variable and immediately return it"
patterns, and so clippy now warns about them.
- We needed to adjust the explicit captures (`use<...>`)
in a couple of our RPIT instances.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
|
| |
|
|
|
| |
Since we now allow it to be turned on, we can include it among our
supported protocols.
|
| | |
|
| |\
| |
| |
| |
| | |
Use congestion control when "flowctl-cc" is enabled
See merge request tpo/core/arti!3118
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, we've been using `ClientCirc::path_ref()` to get the *only*
path of a circuit. Now that `ClientCirc` is a handle to a tunnel reactor
(which may or may not be multi-path), we need to decide for each call
site of `path_ref()`, if we actually want *all* paths in the tunnel, or
if we expect the tunnel to be single-path and thus want the *only* path
in the tunnel.
I've added two new APIs to address this: `all_paths()`, for getting all
the paths in the tunnel, and `single_path()` for getting the only path
in the tunnel, or an error if the tunnel is single-path.
|
| | | |
|
| | |
| |
| |
| |
| | |
When the `send-control-msg` feature is enabled, we reexport it from
`tor-proto`, so it needs to be made `pub`.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Previously the error message would say `Single circuit getter on multi
path tunnel`. The new error message makes it clearer that calling
`ClientTunnel::allow_stream_requests()` on a multi path tunnel is not
supported.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the `allow_stream_requests()` tests which ensures we don't
allow incoming streams on multipath tunnels (because we don't currently
support it).
This also changes `newcirc_ext` to return `ClientTunnel` instead of
`Arc<ClientTunell>` (we need to mutate `ClientTunnel` to manually set
`is_multi_path` on its inner `ClientCirc`).
|
| | | |
|
| | |
| |
| |
| | |
`as_single_circ()` returns an error for multipath tunnels.
|
| | |
| |
| |
| |
| |
| | |
Adapt all tests to use the new ClientTunnel.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The BaseTunnel now has a start_conversation() which takes a TargetHop
meaning it can be used with a multi path tunnel.
The Conversation object has been moved into the tunnel namespace out of
the circuit one.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, the Arc requirement needs to go away because
the Arc<ClientCirc> is now within the ClientTunnel.
This commit also has a rename of the CircuitBuilder to TunnelBuilder in
order to reflect the change that it now builds a ClientTunnel.
There is a slight rename in tor-proto as well just for accuracy.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
And rename it in the process to "PendingClientTunnel".
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce the new Tunnel structs that is planned to expose publicly as a
replacement to `ClientCirc`.
Future commits will make those tunnel objects be used accross the code
base up until tor-proto which than handles Circuit directly.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, some client => tunnel renaming needed to
happen including the comments.
The send_raw_msg() is an experimental and expert mode method that any
tunnel should have access to in order to be able to send whatever
message in whatever tunnel type.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To use the functionality only allowed on single-circuit tunnels (such as
`extend*`), callers will have to call `ClientTunnel::as_single_circ()`
to obtain a handle to the underlying `ClientCirc`.
This is an opinionated design decision that goes against the plan from
[!2790]. It stems from my thinking that it would make more sense to keep
`ClientCirc`, than to merge it into `ClientTunnel`. If we merge the two,
many functions will need become fallible and less ergonomic, because the
user of `ClientTunnel` needs to know whether the `ClientTunnel` consists
of a single-circuit or not. Providing (fallible) access to the
underlying `ClientCirc` of the `ClientTunnel` seems simpler than the
alternative. That being said, I am open to switching back to the
original plan if this design turns out to be annoying to work with.
[!2790]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2790
|
| |
|
|
|
|
|
| |
This command is supposed to return an error when handled by a tunnel
reactor that has more than one circuit.
Prevents the `ConfluxSet::take_single_leg()` bug fixed in 00bb0628.
|
| |
|
|
| |
This was fixed in !3091
|
| | |
|
| |
|
|
|
|
|
| |
This slightly reduces the amount of code we need to maintain.
This also drive-by fixes a bug in `ConfluxSet::take_single_leg`, which
previously never actually checked if the conflux set was of size one.
|
| |
|
|
|
| |
This method will enable us to remove some duplicated code, as well as
the `element_idx` function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit prevents us from ever deciding that another relay
supports CGO, which prevents us from trying to negotiate it.
It also adds an assertion to make sure that we haven't tried to
negotiate it.
We can remove this once we're ready to have CGO turned on:
right now it's blocked on being able to negotiate CC.
I'm adding this so we can merge this branch (so that I can stop
rebasing it.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We now take an enum describing whether we are doing no negotiation,
HsV3 negotiation, or full negotiation. This lets us do away with
the notions of default relay crypto, and of declaring post-facto
that no negotiation has occurred.
|
| |
|
|
|
| |
Instead call it compatible_with_cgo, which is what we actually
care about in this context.
|
| |
|
|
| |
Let's see if it works!
|
| | |
|
| |
|
|
|
| |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`DataReader` -> `DataReaderInner`
`DataReaderNew` -> `DataReader`
This means that the `DataReader` now supports XON/XOFF flow control
using the `XonXoffReader`.
This means that it can receive requests for a new drain rate from the
reactor, and can send the new drain rate to the reactor once there is no
more stream data queued.
|
| |
|
|
| |
This will later become `DataReader`.
|
