aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: disable flowctrl sidechannel mitigations for relaysSteven Engler7 days2-11/+21
| | | | | | | | The end result should be: 1. outgoing streams - enable sidechannel mitigations 2. incoming hs streams - enable sidechannel mitigations 3. incoming exit streams - disable sidechannel mitigations
* tor-proto: add `StreamHandler::flowctrl_sidechannel_mitigations()`Steven Engler7 days1-0/+4
|
* tor-proto: add `WithSidechannelMitigations` for flow ctrlSteven Engler7 days1-3/+5
|
* tor-proto: 'expect' -> 'allow' in `CircReactorHandle`Steven Engler2026-08-111-2/+2
| | | | | | | | | | This fixes an `unfulfilled_lint_expectations` warning. tor-proto conditionally sets a global `allow(unused)`, and if you have an `expect(unused)` field within an `allow(unused)` struct, rust seems to warn with 'unfulfilled_lint_expectations'. https://github.com/rust-lang/rust/issues/160942
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-035-12/+12
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-036-19/+19
| | | | | | | | | We have decided that instead of "uniq_id" in logging, we'll use the "<domaine>-[<type>]-id" syntax to indicate who is that unique ID. This commit only renames circuit's unique ID to "circ_uniq_id". Signed-off-by: David Goulet <[email protected]>
* proto: Log both UniqId and CircId when possibleDavid Goulet2026-08-037-24/+85
| | | | | | | | | | This commit only affects logging. Whenever possible, log both the UniqId and CircId. This also changes the log lines which is now "uniq_id=" and "circ_id=" as the UniqId is internal and circ_id (CircId) is protocol level. Signed-off-by: David Goulet <[email protected]>
* proto: Rename CircId and UniqId variable nameDavid Goulet2026-08-031-1/+1
| | | | | | | | | | | | | | | A CircId is now a circ_id and a UniqId is a unique_id so we stop confusing them in the code. Furthermore, channel_id that are CircId are now circ_id. Channel IDs are different and encoded internally into a UniqId. This is the first step to clarify semantic before we change the logging to log both unique ID and circ ID. No behavior change. Signed-off-by: David Goulet <[email protected]>
* tor-cell: rename `XonKbpsEwma` to `XonKBpsEwma`Steven Engler2026-07-301-2/+2
|
* Merge branch 'create-fast' into 'main'opara2026-07-301-34/+5
|\ | | | | | | | | tor-protover,tor-proto: Add and use a new `subprotocol_restricted_set` macro See merge request tpo/core/arti!4241
| * tor-proto: use `subprotocol_restricted_set` macroSteven Engler2026-07-301-34/+5
| |
* | tor-proto: fix tests when `feature = relay`Steven Engler2026-07-291-1/+1
|/ | | | | | | | | | | | ```text $ cargo test -p tor-proto --features relay [...] error[E0405]: cannot find trait `IncomingStreamRequestFilter` in this scope --> crates/tor-proto/src/circuit/reactor.rs:631:10 | 631 | impl IncomingStreamRequestFilter for AllowAllStreamsFilter { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope ```
* tor-proto: add a TODO for crypt protocol and cc alg logicSteven Engler2026-07-271-0/+4
|
* tor-proto: add `HandshakeSubprotocols`Steven Engler2026-07-271-6/+40
| | | | | | The advantage of this over using a `SubprotocolRequest` is that we can use the type system to ensure it only has subprotocols that are allowed during a handshake.
* tor-proto: remove `CircNetParameters::extend_by_ed25519_id`Steven Engler2026-07-271-2/+0
| | | | | We never used this, it was just needed because we used to convert to a `CircParameters` which required this.
* tor-proto: add `HopSettings::from_handshake_params()`Steven Engler2026-07-271-1/+91
| | | | | | | | | | | | | | | ... and also remove `CircNetParameters::as_circ_parameters()`. We used to call `HopSettings::from_params_and_caps()` when handling incoming circuit requests, but this didn't really make sense because we already know exactly what settings we want. The new `HopSettings::from_handshake_params()` takes the exact settings we want, which means we can also skip constructing a `CircParameters` and use the raw consensus `CircNetParameters`. Most of the code in `CircNetParameters::as_circ_parameters()` has been migrated in some form to `HopSettings::from_handshake_params()`.
* proto: Include the actual cell command in an error messageGabriela Moldovan2026-07-231-3/+5
| | | | | | | This can happen if we get an unexpected BEGIN_DIR/RESOLVE too, so we can't hard-code "BEGIN" in the error message. Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4230#note_3439258,
* proto: Remove feature-gating from CircHop::handle_msg()Gabriela Moldovan2026-07-232-5/+1
| | | | | | | | | | | | | | | This feature-gating has been a source of confusion, and it unnecessarily complicates the stream message handling flow. I've previously argued in favour of keeping it, in the spirit of a belt and braces approach to message validation, but I've been convinced that in this particular case, the feature-gate is more trouble than it's worth. What makes things worse is that the `CircHop::handle_msg()` function was designed poorly (by yours truly). I plan on refactoring it at some point, hopefully soon. There is a TODO about this below its doc comment.
* proto: Adjust feature-gating around incoming streamsGabriela Moldovan2026-07-221-1/+1
| | | | | This applies to relays too, not just onion services (we need to to handle BEGIN/BEGIN_DIR/RESOLVE).
* proto: Allow HsV3 to use cgo.Nick Mathewson2026-07-021-2/+8
|
* proto: Do not automatically disable CC with hsv3.Nick Mathewson2026-07-021-5/+0
| | | | | | | We _already_ do not include FLOWCTRL_CC as a listed protocol among the capabilities we provide, when we make a virtual hop. This branch will make that behavior even more certain, by not looking at required-client-protocols any longer.
* proto: Add TODO about the eventual client-side reactor rewriteGabriela Moldovan2026-07-021-0/+10
| | | | | See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4188#note_3432579
* proto: Allow BeginDir and Resolve messages in the stream reactor (fmt)Gabriela Moldovan2026-07-011-1/+3
|
* proto: Allow BeginDir and Resolve messages in the stream reactorGabriela Moldovan2026-07-011-9/+30
| | | | | | | Previously, these would fail to parse, because the (WIP) stream reactor assumed all streams would be exit (BEGIN) streams. Closes #2613
* proto: Add expect(unused) where neededGabriela Moldovan2026-06-292-0/+3
| | | | | | | | | | | Now that relays no longer use `CtrlCmd::AwaitStreamRequests`, some of these fields are unused. I'm leaving them in for now, but we should remove them if they're still unused after we finish the circ reactor impl. I'm not removing `AwaitStreamRequests`, because it will be needed by onion services, when we replace the old client circuit reactor with the new one.
* proto: Support passing a stream request filter to the reactorGabriela Moldovan2026-06-291-1/+47
| | | | | | | | | Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577
* tor-proto: pass correct chan msg cmd to `decrypt_outbound()`Steven Engler2026-06-241-0/+20
| | | | | | | | | | Instead of converting the `RelayEarly` message to a `Relay` message, we add a new `RelayMaybeEarlyChanMsg` restricted message set that can hold either. Previously we were passing the wrong channel message command to `decrypt_outbound()`, which would cause the decryption to fail for relay crypto algorithms that use the command.
* proto: Rename LocalApplicationStream for clarityGabriela Moldovan2026-06-231-4/+4
| | | | | See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4139#note_3429586
* proto: Rework error handling in `HopMgr::get_or_spawn_reactor()`Gabriela Moldovan2026-06-231-12/+7
| | | | | | | | | | This reworks `get_or_spawn_reactor()` to return `Error` instead of `ReactorError`. The main change here is that we now have a dedicated `Error::Spawn` variant for `SpawnError`s, instead of mapping these to `ReactorError` (which actually triggers a clean shutdown, which is not quite what we want here).
* proto: Simplify StreamEvent::LocalStreamClosed (fmt)Gabriela Moldovan2026-06-231-1/+6
|
* proto: Simplify StreamEvent::LocalStreamClosedGabriela Moldovan2026-06-231-15/+4
| | | | | This doesn't need to contain the `CloseStreamBehavior` or `TerminateReason`, because we always use the same ones.
* proto: Rename StreamEvent::Closed to LocalStreamClosedGabriela Moldovan2026-06-231-5/+5
| | | | | | | I realized the previous naming was ambiguous. Hopefully this makes it clear that this `StreamEvent` triggers when the MPSC channel connecting the reactor to the local application stream (for example the local TCP connection of the stream, in the case of exit streams) is dropped.
* proto: Implement ClosePendingStream in the stream reactorGabriela Moldovan2026-06-233-5/+40
| | | | Closes #2590
* proto: Add a helper function for handling closed streams (fmt)Gabriela Moldovan2026-06-231-10/+10
|
* proto: Add a helper function for handling closed streamsGabriela Moldovan2026-06-231-6/+22
| | | | This will soon be reused for implementing `CtrlMsg::ClosePendingStream`.
* proto: Add a new StreamReactor control message for closing streamsGabriela Moldovan2026-06-231-3/+25
| | | | | | | | | | | | | | | This will be sent by the FWD reactor. Essentially, this going to be the final control message in the chain `IncomingStream::reject()` -> `RelayCirc::reject()` -> `forward::CtrlCmd::ClosePendingStream`-> `HopMgr::close_pending()` -> `stream::CtrlCmd::ClosePendingStream` -> stream gets removed from the stream map, END sent Part of #2590
* proto: Update docs to clarify where the StreamReactor cell sender isGabriela Moldovan2026-06-231-1/+2
|
* proto: Add a control message for closing pending streams (fmt)Gabriela Moldovan2026-06-231-3/+4
|
* proto: Add a control message for closing pending streamsGabriela Moldovan2026-06-231-1/+40
|
* proto: Replace StreamMsg with a new CtrlMsg typeGabriela Moldovan2026-06-234-26/+32
| | | | | | | This replaces the `StreamMsg` `StreamReactor` sender with a new `CtrlMsg` type. This `CtrlMsg` currently only has a `DeliverStreamMsg` variant (which is the same as the old `StreamMsg` type), but will soon grow another variant, for terminating a stream.
* proto: Update tests to use the new stream exportsGabriela Moldovan2026-06-171-4/+4
| | | | The tests don't compile otherwise.
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-093-0/+3
| | | | | | | | | | | | This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit.
* proto: Add a new channel -> circuit queue typeGabriela Moldovan2026-06-081-0/+371
| | | | | | | | | | | | | | | | | | | | | | | This adds new a `CircuitRxSender`/`CircuitRxReceiver` queue type. The corresponding (`Sink`-link) sender and `Stream` implementations prioritize the delivery of `DESTROY` messages, which get delivered immediately, even if there are other messages queued in the underlying MPSC message queue. We are okay with the resulting data loss, because inbound DESTROY can be indicative of malicious activity on the circuit. We choose to err on the safe side, and free up the resources associated with such circuits as soon as possible. DESTROY messages are also sent by relays when they're about to hibernate, and by clients once they've decided to stop using a circuit. In the latter case, the lack of an `RELAY_COMMAND_END_ACK` does mean that this prioritization can cause data loss in cases where the client closes the circuit immediately after END-ing a stream. However, this is a deficiency in the protocol, and not something we want to fix by implementing custom flushing logic in the reactor. See torspec#196 and the discussion in #2490. Part of #2490
* tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-212-5/+13
|
* tor-proto: move memquota stream account arg to last positionSteven Engler2026-05-212-3/+3
| | | | This better matches nearby code.
* tor-proto: clean up `CIRCUIT_BUFFER_SIZE`Steven Engler2026-05-212-8/+1
|
* tor-proto: move more stream queue init to reactorSteven Engler2026-05-212-47/+73
| | | | | | | | | | | | | | | | | | | | Previously when initializing a stream, we constructed most of the stream-related queues outside of the reactor and passed the relevant halves of the queues (senders or receivers) into the reactor. A downside of the above approach is that the reactor may be better informed about what queues to construct, and how to construct them. For example the reactor knows what type of flow control that the hop is using, so it knows whether we need queues for passing rate limits and drain rates for XON/XOFF flow control. This commit moves the construction of these queues into the reactor and passes the relevant halves out of the reactor. In the future we can make better decisions about which queues are needed depending on the flow control method used instead of always constructing them (see arti#2068). Reviewing with `--color-moved` might be helpful as a few lines have been moved.
* tor-proto: add `ReactorStreamComponents` to bundle return valsSteven Engler2026-05-202-6/+23
|
* tor-proto: always use a bounded mpsc queue for streamsSteven Engler2026-05-201-13/+7
| | | | | | | | | | | | Whether a stream queue should be bounded or unbounded is a decision that needs to be made at runtime depending on the type of flow control used, not at build-time. Window-based flow control should be bounded and XON/XOFF flow control should be unbounded. If we wanted to support both bounded and unbounded queues, it would take a bunch of boilerplate code to wrap the senders and receivers in enums. Instead we make the queue always bounded, but use a large bound for XON/XOFF flow control.
* tor-proto: move stream incoming queue init to reactorSteven Engler2026-05-202-24/+33
| | | | | | | | | | | The stream queue length (for messages incoming from the Tor network) depends on the type of flow control we're using for the hop. Currently we construct the stream queue outside of the circuit reactor, but we don't have the flow control information here. Instead of constructing the stream queue outside of the reactor and passing the sender into the reactor, we construct the stream queue inside of the reactor and pass the receiver out of the reactor.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 19:23:44 +0000