| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the msg.rs file containing all the allowed message sets based on the
channel type and direction. They are also namespaced by link protocol
version.
Unused at this commit. They will be used by the channel reactor along
the channel type and link protocol version in order to know if the
message is allowed or not. See is_allowed() helper function in this
commit.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The ChannelType indicates the type of channel in order to dictate which
message is allowed on it. The value use the Initiator and Responder
terminology from tor-spec documents.
At this commit, we only have client channel meaning the
"ClientInitiator" type.
In future commits, the channel type will be used by the channel reactor
to restrict which message is allowed or not.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
This tries to explain that the amount of incoming data we choose to
buffer on an arti stream doesn't really matter for arti's socks proxy,
since the amount of data buffered by the kernel is significantly higher.
|
| | |
|
| |
|
|
| |
This restores the pre-374889d34aa0 behaviour.
|
| |\
| |
| |
| |
| | |
proto: Add a placeholder for the relay reactor.
See merge request tpo/core/arti!3162
|
| | |
| |
| |
| | |
Wraps an overly-long line for consistency.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
A "tunnel" is a higher level concept we'll want to avoid using from now
on when talking about the proto implementation.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
| | |
| |
| |
| |
| |
| |
| | |
This reorganizes the `relay_tunnel` module as per @dgoulet's
[suggestion].
[suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a placeholder, and will likely change quite a bit in the near
future. In particular, much of this is copied from the client tunnel
reactor (a future change will refactor both of them to reduce/minimize
code duplication).
I'm adding this placeholder because the channel code will soon
need the ability to create and launch circuit reactors.
|
| | |
| |
| |
| | |
We will soon need this in the relay reactor.
|
| | |
| |
| |
| | |
Part of #1447
|
| | |
| |
| |
| |
| |
| |
| | |
The new relay tunnel reactor will live in this module for now. This is
temporary, as I expect we will soon need to reorganize this crate a
little bit, to more clearly separate the client-specific parts from the
relay ones.
|
| | |
| |
| |
| |
| | |
The relay-specific logic, including the new relay tunnel/circuit
reactor, will be gated behind this feature.
|
| |\ \
| |/
|/|
| |
| | |
Fix clippy errors on nightly
See merge request tpo/core/arti!3148
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```text
warning: duplicated attribute
--> crates/tor-hsservice/src/timeout_track.rs:630:14
|
630 | #![allow(clippy::needless_pass_by_value)] // TODO hoist into standard lint block
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
| |/
|
|
|
|
|
|
|
| |
This replaces a `send_unbounded()` call with `send_msg()`. Now
`send_msg()` is the only place where we call `send_unbounded()` in the
tunnel reactor, which makes it a bit easier to see which callsites have
the potential to cause buffering in the channel sink.
Prompted by #2112
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
(We can't negotiate the one without the other.)
|
| | |
| |
| |
| | |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
Bump MSRV to Rust 1.85
Closes #2095
See merge request tpo/core/arti!3128
|
| | |
| |
| |
| |
| | |
(We were unable to do this before, since it required a rust version
we didn't have.)
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
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`.
|
| | | |
|
