aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge branch 'clippy_warning' into 'main'Jim Newsome2026-07-131-1/+1
|\ \ | | | | | | | | | | | | multiple crates: Fix clippy warnings See merge request tpo/core/arti!4203
| * | multiple crates: Fix clippy warningshjrgrn2026-07-101-1/+1
| |/
* | Merge branch 'upgrade-cipher' into 'main'gabi-2502026-07-134-14/+25
|\ \ | |/ |/| | | | | Upgrade cipher, aes, and ctr. See merge request tpo/core/arti!4195
| * Upgrade cipher, aes, and ctr.Nick Mathewson2026-07-134-14/+25
| |
* | hsclient: Support protocol negotiation for CGO and flowctrl-ccNick Mathewson2026-07-021-0/+6
| |
* | 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: log virtual hop additions at trace.Nick Mathewson2026-07-021-0/+2
| | | | | | | | We do something similar with non-virtual hops at !4076.
* | proto: Improve/clarify documentation on extend_virtual.Nick Mathewson2026-07-021-0/+8
| |
* | Merge branch 'stream-msg-parse' into 'main'gabi-2502026-07-022-23/+53
|\ \ | | | | | | | | | | | | | | | | | | proto: Allow BeginDir and Resolve messages in the stream reactor Closes #2613 See merge request tpo/core/arti!4188
| * | 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: Re-enable IncomingCmdChecker test (fmt)Gabriela Moldovan2026-07-011-2/+6
| | |
| * | proto: Re-enable IncomingCmdChecker testGabriela Moldovan2026-07-011-14/+7
| | | | | | | | | | | | | | | These assertions no longer fail now that the stream reactor is able to handle non-`BEGIN` streams.
| * | 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
* / Upgrade to itertools 0.15.0Nick Mathewson2026-07-011-10/+9
|/ | | | | | Additionally, fix itertools usage in maybenot_padding.rs The definition of `Position` changed in 0.15.0.
* proto: Add test for the incoming stream cmd allow listGabriela Moldovan2026-06-301-0/+48
| | | | | | | Tests that the customizable `IncomingCmdChecker` added for #2606 is doing its job, by ensuring that the circuit reactor doesn't emit `IncomingStream`s for incoming streams created with commands that are not in the reactor's allow list.
* proto: Update tests to pass the incoming cmd allow list to the reactor (fmt)Gabriela Moldovan2026-06-301-12/+21
|
* proto: Update tests to pass the incoming cmd allow list to the reactorGabriela Moldovan2026-06-301-10/+12
|
* proto: Pass the allowed incoming commands to the relay reactorGabriela Moldovan2026-06-302-1/+3
| | | | | | | | The `CreateRequestHandler` now passes the list of allowed "incoming stream request" commands (i.e. BEGIN, BEGIN_DIR, or RESOLVE) to the reactor, replacing the hard-coded command list. Closes #2606
* proto: Pass the allowed incoming commands to CreateRequestHandlerGabriela Moldovan2026-06-302-0/+14
| | | | | | | | | | | This enables us to make these configurable: any relays that are not configured to be an exit will exclude BEGIN and RESOLVE from their list of allowed commands, causing exit and DNS streams to be rejected as soon as the BEGIN/RESOLVE cell is received in the circuit reactor. Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4145#note_3430345 Part of #2606
* proto: Remove confusing blurb about IncomingStream handlingGabriela Moldovan2026-06-291-3/+5
|
* proto: Clarify wording in relay reactor constructorGabriela Moldovan2026-06-291-1/+5
|
* proto: Say why INCOMING_BUFFER is set to STREAM_READER_BUFFERGabriela Moldovan2026-06-291-0/+5
|
* 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: Remove RelayCirc::allow_stream_requests()Gabriela Moldovan2026-06-291-141/+3
| | | | | | | | | | | | | We don't need it anymore now that `RelayCirc`s always allow incoming stream requests. The previous design, where you could build a `RelayCirc` that didn't allow stream requests, was a leftover from the onion service `ClientCirc` implementation that this was inspired from (onion services *do* need the two to be decoupled, because incoming stream requests are only allowed on the virtual hop, after it's established). Closes #2582
* proto: Pass an IncomingStreamRequestFilter factory to the create handlerGabriela Moldovan2026-06-293-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements what we discussed in `doc/dev/notes/relay-streams.md` (lines 218-234): > Currently, to allow incoming stream requests on a circuit, > you first need to call `RelayCirc::allow_stream_requests()` > to install a `CmdChecker` and `IncomingStreamRequestFilter`. > This is not ideal, because `allow_stream_requests()` will need to be > called unconditionally, on each `RelayCirc`, > right after it's created in the `CreateHandler` impl > (which in turn, would mean making `handle_create()` async too, > because `allow_stream_requests()` is async, which wouldn't be great). > > So, the first step here is to rework the `RelayCirc` API to make relay circuits > be constructable with a list of allowed `RelayCmd`s and `IncomingStreamRequestFilter` > from the get-go ([#2582]), and to get rid of `allow_stream_requests()`, > which will enable the `CREATE*` handler to remain non-`async`. > > In any case, the `CREATE*` handler will still require some changes, > because it needs to be initialized with an `IncomingStreamRequestFilter`, I am not sure using an `IncomingStreamRequestFilter` "factory" is necessarily the right approach here, but the circuit `Reactor`'s constructor needs to take an `IncomingStreamRequestFilter`, and `IncomingStreamRequestFilter` is not `Clone` (and FWIW, I think it's better if we don't make it `Clone`). One obvious limitation is that the `IncomingStreamRequestFilter` of the circuit reactor is fixed for the entire lifetime of the circuit. In practice, I don't think this is going to be a problem, because the arti-relay `IncomingStreamRequestFilter` is only going be used for * preventing single-hop exit streams * per-circuit rate-limiting. Both of these checks will require the filter to have access to a recent `NetDir`, which is straightforward if the filter has an Arc<dyn NetDirProvider> (as mentioned in doc/dev/notes/relay-streams.md, `NetDirProvider` has a handy non-async `timely_netdir()` function we can use). And since these checks are based on consensus params, we don't really need to ever update an already-built circuit with a new `IncomingStreamRequestFilter` (because all `IncomingStreamRequestFilter` will have the ability to obtain a fresh `NetDir` as needed). Nevertheless, I left a TODO about this, because I expect this type to change once we figure out all the other pieces needed for #1448.
* proto: Return IncomingStreams stream from relay reactor constructor (fmt)Gabriela Moldovan2026-06-291-4/+4
|
* proto: Return IncomingStreams stream from relay reactor constructorGabriela Moldovan2026-06-292-52/+122
| | | | Part of #2582
* proto: Support passing a stream request filter to the reactorGabriela Moldovan2026-06-293-4/+83
| | | | | | | | | Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577
* tor-proto: add some comments about handshake server argumentsSteven Engler2026-06-251-0/+5
|
* tor-proto: implement the ntor (non-v3) handshakeSteven Engler2026-06-241-5/+65
|
* tor-proto: update a comment in `CreateRequestHandler`Steven Engler2026-06-241-4/+2
|
* tor-proto: move `RelayLayer` split into helperSteven Engler2026-06-241-4/+21
|
* tor-proto: prepare for ntor handshakesSteven Engler2026-06-241-9/+34
|
* tor-proto: pass correct chan msg cmd to `decrypt_outbound()`Steven Engler2026-06-242-5/+27
| | | | | | | | | | 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.
* Merge branch 'incoming-reject' into 'main'gabi-2502026-06-248-85/+272
|\ | | | | | | | | | | | | proto: Add circ reactor scaffolding for rejecting pending streams Closes #2590 See merge request tpo/core/arti!4139
| * 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-232-13/+27
| | | | | | | | | | | | | | | | | | | | 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: Remove unnecessary result mappingGabriela Moldovan2026-06-231-1/+1
| | | | | | | | This already returns `()` in the `Ok` case.
| * 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: Implement RelayCirc::close_pending()Gabriela Moldovan2026-06-231-4/+17
| | | | | | | | Closes #2590
| * proto: Add a control message for closing pending streams (fmt)Gabriela Moldovan2026-06-231-3/+4
| |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 01:31:24 +0000