summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
* 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: Pass an IncomingStreamRequestFilter factory to the create handlerGabriela Moldovan2026-06-291-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-292-3/+36
| | | | | | | | | 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-241-5/+7
| | | | | | | | | | 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: Make the new reject_stream() test check the END cell tooGabriela Moldovan2026-06-231-1/+5
|
* proto: Factor helper macro out of test functionGabriela Moldovan2026-06-231-17/+17
| | | | This is just code motion
* proto: Refactor test macro to not rely on function contextGabriela Moldovan2026-06-231-6/+7
| | | | | | I am about to move this out of the `extend_and_forward()` test, because I want to reuse it in the new `reject_stream()` test for checking that the relay wrote an END cell to the stream.
* proto: Add a test for rejecting an incoming stream in the relay reactorGabriela Moldovan2026-06-231-0/+40
| | | | | | | | This test currently fails, because `IncomingStream::reject()` calls `RelayCirc::close_pending()` under the hood, which isn't implemented yet. Part of #2590
* tor-proto: circ handshake now always uses NONE destroy reasonSteven Engler2026-06-121-15/+5
|
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-091-0/+1
| | | | | | | | | | | | 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.
* Merge branch 'destroy-cell3' into 'main'gabi-2502026-06-082-2/+3
|\ | | | | | | | | proto: Add a new channel -> circuit queue type See merge request tpo/core/arti!4025
| * proto: Update the tests to use the new CircuitRx{Receiver,Sender}sGabriela Moldovan2026-06-081-1/+1
| |
| * proto: Replace CircuitRx{Sender,Receiver} with new channel typeGabriela Moldovan2026-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | This is needed for relays as part of #2490. Note that changing this type affects the client implementation too (i.e. clients will start prioritizing inbound DESTROY, discarding any queued data without forwarding it to their local streams). But that's okay, because it will generally only affect misbehaving clients, and clients unlucky enough to encounter a hibernating relay.
| * proto: Remove now-unused importGabriela Moldovan2026-06-081-1/+1
| | | | | | | | | | `CircuitRxSender` is no longer a `Sink`, so we don't need this import anymore.
* | proto: Enable the relay exit stream testGabriela Moldovan2026-06-081-1/+0
|/ | | | | This passes now that we can build a `DataStream` without a `ClientDataStreamCtrl`.
* proto: Fix inverted cert sig and AUTHENTICATE compareDavid Goulet2026-06-021-4/+1
| | | | | | | | | | | | Missed at review and no unit tests at the time catched those. The next commit has a unit tests to make sure these checks are now valid. Fixes #2501 Fixes #2502 Special thanks to Moumen Alaoui for reporting this early! Signed-off-by: David Goulet <[email protected]>
* proto: Remove TODOs about flushing pending dataGabriela Moldovan2026-05-262-8/+0
| | | | | | We decided the reactor is the wrong place to handle this. See discussion in #2490
* proto: Remove unused asyncGabriela Moldovan2026-05-201-3/+2
|
* proto: Make TRUNCATE trigger a proto violationGabriela Moldovan2026-05-202-5/+25
|
* proto: Add some tests for DESTROY handlingGabriela Moldovan2026-05-201-1/+60
|
* proto: Make do_create2_handshake() check EXTENDED2 was sentGabriela Moldovan2026-05-201-1/+19
| | | | | | | | | | | | | | This adds an extra assertion that ensures the relay reactor does in fact send an EXTENDED2 on its towards-the-client channel after receiving the CREATED2 response from the fake hop. This check is nice to have in general, but the main reason I'm doing this now is because for the DESTROY tests I'm about to add, I need the inbound MPSC queue (towards the client) drained of these handshake messages in order to check that the "next" cell we've sent is a destroy. I could've added some custom code to drain it just for the purposes of that test, but I think it's better to have `do_create2_handshake()` take care of it.
* proto: Extend helper to check that DESTROY was sent in both directionsGabriela Moldovan2026-05-201-7/+21
|
* proto: Rename a test helper and adjust its docsGabriela Moldovan2026-05-201-7/+6
| | | | | | | | The new name is (hopefully) a bit more descriptive. I'm planning on extending this function soon to support checking if a DESTROY has been sent on the outbound channel too, so I'm tweaking the docs a bit in preparation for that.
* proto: Return the CircId from test handshake helperGabriela Moldovan2026-05-201-2/+4
| | | | I'll soon need this for a DESTROY test.
* proto: Add test helper for sending AnyChanMsgsGabriela Moldovan2026-05-201-0/+5
|
* proto: Add a comment clarifying why we don't need to propagate DESTROYGabriela Moldovan2026-05-201-0/+7
|
* proto: Adjust DESTROY-related logs in the backward reactorGabriela Moldovan2026-05-201-2/+6
| | | | | | | This changes a debug log to have the same format as the corresponding DESTROY-related log from the forward reactor. Part of #2490
* proto: Pass the cell by reference to resolve a warningGabriela Moldovan2026-05-201-3/+2
|
* proto: Log a message when a forward DESTROY comes alongGabriela Moldovan2026-05-201-3/+15
| | | | Part of #2490
* Upgrade rand crates to 0.10.Wesley Aptekar-Cassels2026-05-122-2/+2
| | | | | | | | | | | When the circ-padding feature is enabled, we use maybenot, which does not yet support rand 0.10. In the meantime, enabling this feature pulls in rand 0.9. This is not ideal, but should be okay as a temporary situation. This also replaces the use of ReseedingRng (which was removed in 0.10) with the reseeding_rng crate. This is somewhat less performant, but it should be okay.
* proto: Wrap PeerInfo in Arc<>Gabriela Moldovan2026-04-232-4/+4
| | | | | | To avoid copying the same information for every circuit, as suggested by @opara in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3399497
* proto: Avoid collecting the chan identities in RelayIdSetGabriela Moldovan2026-04-231-10/+2
| | | | | It doesn't make sense to do so, as pointed out by @opara in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3398956
* proto: Use PeerInfo in the extend handlerGabriela Moldovan2026-04-232-3/+4
| | | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3397922
* proto: Add test ensuring we won't extend to the previous hopGabriela Moldovan2026-04-231-1/+43
|
* proto: Reject EXTEND2 targeting the previous hop in the circuitGabriela Moldovan2026-04-231-1/+13
| | | | | | | The relay reactor will now reject any EXTEND2 that tries to extend the circuit to a hop that shares any identities with our previous hop. Closes #2415
* proto: Give the ExtendRequestHandler a copy of the inbound peer infoGabriela Moldovan2026-04-233-1/+8
| | | | | This will soon be used for preventing the circuit from being extended to the previous hop (#2415).
* proto: Fix broken doc link in extend handlerGabriela Moldovan2026-04-231-1/+3
|
* proto: Extract EXTEND2 handling into a new moduleGabriela Moldovan2026-04-232-200/+254
| | | | | | | | | The EXTEND2 handling logic is fairly self-contained, so I'm moving it outside of the `Forward` handler. This refactoring enables us to add more context to the handler (i.e. the inbound channel identities needed for #2415) without cluttering the `Forward` implementation. I recommend reviewing this commit with `git diff --color-moved`.
* proto: Make the CreateRequestHandler::new() take the ntor keysDavid Goulet2026-04-211-14/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* relay: Use the new RelayNtorKeys for the create handlerDavid Goulet2026-04-211-9/+5
| | | | Signed-off-by: David Goulet <[email protected]>
* Merge branch 'rm-var-suffix' into 'main'David Goulet2026-04-201-4/+4
|\ | | | | | | | | proto: Remove dummy suffixes from variable name See merge request tpo/core/arti!3903
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 00:28:47 +0000