aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
...
* 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: 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-301-0/+11
| | | | | | | | | | | 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: 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
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 20:42:19 +0000