summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel
Commit message (Collapse)AuthorAgeFilesLines
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-282-3/+3
| | | | | | | This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.
* proto: Only allow VERSIONS cell for the new handshake stateDavid Goulet2025-08-272-51/+20
| | | | | | | | | Due to this, it is not possible to get a VPADDING before because it requires a link protocol version to decideon the encoding: https://gitlab.torproject.org/tpo/core/torspec/-/issues/366 Signed-off-by: David Goulet <[email protected]>
* proto: Remove the AUTHORIZE as a parsable cellDavid Goulet2025-08-212-19/+2
| | | | | | | | | | | | | The AUTHORIZE cell command is simply reserved but not defined. The tor specification, at this point in time, is allowing such cell before the handshake starts but it is very unclear on what ordering is allowed nor how many can are allowed. C-tor silents drop them like VPADDING and so clearly unused. Instead of dealing with it, simply remove its support but keeping its reserved number. Signed-off-by: David Goulet <[email protected]>
* proto: Add a channel handler comment and a fixDavid Goulet2025-08-211-3/+8
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Return AUTHORIZE, VPADDING and VERSIONS at handshakeDavid Goulet2025-08-212-24/+65
| | | | | | | | When starting a handshake, we were only expecting a VERSIONS which is not what the protocol say. An AUTHORIZE and VPADDING can arrive before a VERSIONS. Signed-off-by: David Goulet <[email protected]>
* proto: Allow padding in all channel message setsDavid Goulet2025-08-211-3/+13
| | | | | | | | | | | | | | First of all, VPADDING has been added in link protocol version 3 so it was missing from v4. Second, after closely looking at C-tor and the spec, it appears that we allow VPADDING at any point on a channel which should simply be silently dropped. Any number in any order. Third, couple sets were missing the PADDING cell which is only allowed on an open channel. Signed-off-by: David Goulet <[email protected]>
* tor-proto: simplify some match statementsSteven Engler2025-08-201-46/+26
|
* proto: Change (crate) to (super) for all objects in msg.rsDavid Goulet2025-08-201-25/+25
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Cleanup allow(unused)David Goulet2025-08-202-4/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Unit tests for channel handlerDavid Goulet2025-08-201-1/+107
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename OutboundClientHandshakeDavid Goulet2025-08-201-6/+6
| | | | | | | | | Use the specification terminology which is also the same for ChannelType. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Make the OutboundClientHandshake use new cell handlerDavid Goulet2025-08-203-178/+90
| | | | | | | | | | | | | | | | | Use the ChannelFrame<> for the entirety of the outbound client handshake that is the ClientInitiator channel type. With this change, the codec.rs code is not needed anymore along its CodecError as well which has been normalized onto the crate::Error instead in order to simplify error handling and avoid duplication of error types. Unit tests have been modified to reflect this change of what can be done with a channel frame. Also renamed to focus on client behavior. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add channel cell handlerDavid Goulet2025-08-201-0/+561
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The handler.rs file contains a generic "ChannelCellHandler" which is split into three different handler depending of the channel state (new, handshaking or open). These handlers implement Encoder/Decoder so we can give a ChannelCellHandler to a asynchronous_codec::Framed along a TLS stream. That cell handler is also in charge of tracking the CLOG/SLOG (see tor-spec), running digest of cells seen, which is used to authenticate a channel for the Relay <-> Relay case. This ChannelCellHandler auto transitions as the setters function are used. The handshake code will use this to advance the handler. Each handler uses a MessageFilter from msg.rs in order to allow or not to return the message. A keen eye will notice that we can avoid encoding a message if we don't need but we will decode all possible messages and only then allow it or not. The channel cell handler is not used at this commit. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add message filtering to restricted message setsDavid Goulet2025-08-201-2/+361
| | | | | | | | | | | | | | | | | This adds the code in msg.rs to be able to filter an inbound or outbound message on a channel. Each link protocol version implement a "is_allowed()" which is quite verbose and tests each possibilities for human readability. Then, we have several small struct/enum that are used to describe how a message is filtered. It is still unused at this commit. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add restricted channel message setsDavid Goulet2025-08-201-0/+207
| | | | | | | | | | | | | | | 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]>
* proto: Add ChannelType enumDavid Goulet2025-08-202-2/+12
| | | | | | | | | | | | | | | | 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]>
* tor-proto: report tunnel/channel id as a fieldSteven Engler2025-08-181-2/+2
| | | | This restores the pre-374889d34aa0 behaviour.
* proto: Rename the `tunnel` module to `client` (fmt).Gabriela Moldovan2025-08-181-1/+1
|
* proto: Rename the `tunnel` module to `client`.Gabriela Moldovan2025-08-183-10/+10
| | | | | | 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.
* tor-proto: use error report in tunnel/channel reactorSteven Engler2025-08-071-1/+10
|
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-075-31/+39
| | | | | | | | | | | | | | 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.
* proto: Fix the tunnel/circuit.rs unit testsDavid Goulet2025-08-051-2/+2
| | | | | | Adapt all tests to use the new ClientTunnel. Signed-off-by: David Goulet <[email protected]>
* tor-proto: Log channel, circuit, stream identifiers as structured fields.Gabriela Moldovan2025-06-122-24/+31
| | | | | | | | | | | | | | | | | This changes the `tor-proto` logs to not be prefixed with a channel/circuit/stream ID, but rather to have these IDs attached to the log as structured fields. This change is in preparation for the switch to using `TunnelId`s in the tunnel reactor instead of circuit `UniqId`s. The reason for the change to use structured fields is because future logs will likely need to log the `UniqId`s of the circuits in a tunnel, which will need to either be formatted somehow in the logs, or logged as a structured field (the latter seems like the better option, hence this preparatory change). IMO we should favor structured fields over formatted strings in the logs in general, but that is a bigger project, so I am only doing a spot fix for now.
* proto: temporarily suppress warning; see #2003.Nick Mathewson2025-05-151-2/+2
|
* Include "bug" in all bug error messagesNick Mathewson2025-04-281-1/+1
|
* circ: Remove CircParameters reference in call stackDavid Goulet2025-04-231-2/+1
| | | | | | | | | | | This avoids cloning the object and instead allows us to have a CircParameters per hop on the circuit path. This will come handy with congestion control where each hop might have different congestion control parameters. Part of #1817 Signed-off-by: David Goulet <[email protected]>
* Allow StreamOps import to be unusedNick Mathewson2025-04-091-2/+8
| | | | | This comes up on OSX; I hadn't seen it before, so I assume it is new with Rust 1.86.
* proto: make padding::Parameters construction fallible.Nick Mathewson2025-03-182-22/+104
| | | | | | | The constructor for rand::distr::Uniform is now fallible, so it makes sense to bubble up its restrictions. This is a breaking change.
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-1/+2
| | | | - `Uniform::new_inclusive` is now fallible.
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-182-5/+5
| | | | - The rand::distributions module has been renamed to rand::distr
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-182-2/+2
| | | | - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
* tor-rtmock: allow-Decorate every use of MockSleepProviderIan Jackson2025-03-061-0/+1
| | | | | | | MockSleepProvider and MockSleepRuntime have been declared deprecated by the docs for some time. We're about to mark them `#[deprecated]`. This commit has been split out for clarity of review.
* tor-proto: Add a tunnel module.David Goulet2025-02-203-10/+10
| | | | | | | | | | | | | Move StreamTarget to the tunnel module and the circuit module. From now on streams will be implemented on tunnels, not circuits. This moves `StreamTarget` to the tunnel module. A future change will replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`. This is mostly code motion, best reviewed with `--color-moved`. Signed-off-by: David Goulet <[email protected]>
* tor-proto: remove `use asynchronous_codec as futures_codec`Neel Chauhan2025-02-062-16/+16
| | | | Closes #1690.
* tor-proto: Remove dependency on tor-netdir.Gabriela Moldovan2025-01-151-39/+6
| | | | | | | | This moves the `NetParameters -> KistParams` conversion to `tor-chanmgr`. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2706#note_3147557
* tor-proto: Replace constants with caret_int.Gabriela Moldovan2025-01-151-3/+14
|
* tor-rtcompat: Rename UnsupportedStreamOps to NoOpStreamOpsHandle (fmt).Gabriela Moldovan2025-01-151-1/+1
|
* tor-rtcompat: Rename UnsupportedStreamOps to NoOpStreamOpsHandle.Gabriela Moldovan2025-01-151-2/+2
| | | | | This renames UnsupportedStreamOpsHandle to NoOpStreamOpsHandle for clarity (the old name kind of sounded like the name of an error type).
* tor-proto: Set kist params in channel reactor.Gabriela Moldovan2025-01-151-2/+32
|
* tor-proto: Add CtrlMsg for setting kist options (fmt).Gabriela Moldovan2025-01-151-1/+3
|
* tor-proto: Add CtrlMsg for setting kist options.Gabriela Moldovan2025-01-151-1/+8
|
* tor-proto: Pass a StreamOps handle to the channel reactor.Gabriela Moldovan2025-01-152-2/+14
|
* tor-rtcompat: Big invasive change adding StreamOps bound everywhere.Gabriela Moldovan2025-01-152-10/+19
| | | | | | This is unfortunately necessary, because after the channel handshake, we need to give the channel reactor a `StreamOps` handle to the underlying stream.
* tor-proto: Add KistParams type built from NetParameters.Gabriela Moldovan2025-01-151-0/+60
| | | | | | | | Note: this commit makes `tor-proto` depend on `tor-netdir` (because it adds a `KistParams` type that is buildable from `NetParameters`, which is defined in `tor-netdir`). Closes #1729
* tor-proto: fix bad indentationSteven Engler2025-01-091-3/+3
|
* tor-proto: test `Channel::wait_for_close`Steven Engler2025-01-091-5/+35
|
* tor-proto: `Channel::wait_for_close` return success statusSteven Engler2025-01-091-6/+5
| | | | | | This had a TODO about returning a "status indication instead of just ()" so this commit adds some status indication that we can expand later if needed.
* tor-proto: replace `Channel`s "closed" state handlingSteven Engler2024-12-101-9/+30
| | | | | | | | | | | | | | | Previously `Channel` had two concepts of "closed". There was an atomic flag that was set to `true` at the end `Reactor::run`, and an experimental oneshot channel where the sender was dropped when the reactor was dropped. This commit consolidates these two using the `oneshot_broadcast` module. This means that the behaviour is consistent between both "closed" statuses (`is_closing()` and `wait_for_close()`). A channel is considered closed when its reactor is dropped. This also helps progress towards making the channel reactor cancellation safe (see arti#1756).
* tor-proto: Specify which of the 2 senders is used for sending cells.Gabriela Moldovan2024-11-201-1/+1
|
* Apply deferred rustfmt churnIan Jackson2024-10-092-6/+3
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 11:17:31 +0000