aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: add `StreamHandler::flowctrl_sidechannel_mitigations()`Steven Engler7 days1-0/+6
|
* proto: Extend test to check DESTROY is sent to the next hopGabriela Moldovan8 days1-0/+16
| | | | | | | | | | | | | This extends the `destroy_from_client()` test to also check that a DESTROY received from the client (or, more generally speaking, from the "inbound channel") is actually forwarded to the next hop. The reason the `assert_destroy_sent()` assertion is commented out is specified in the TODO that precedes it (tldr: testing the DESTROY behaviour involves both the channel reactor and the circuit reactor, and our test setup is currently quite limited, in that it doesn't actually exercise the right channel reactor code paths for the *inbound* channel). I plan to address this soon.
* proto: Move assert_cell_is_destroy macro out of helper functionGabriela Moldovan8 days1-15/+15
| | | | I am about to need this in a test.
* proto: Add comments explaining why the tests use DestroyDirection::BackwardGabriela Moldovan8 days1-2/+14
|
* proto: Remove misleading comment and rename misnamed variableGabriela Moldovan8 days1-3/+2
| | | | This fixes an old bad copy-paste that I've just noticed.
* proto: Clarify what read_{inbound,outbound} are forGabriela Moldovan8 days1-0/+14
| | | | This adds an example suggested by opara.
* proto: Update the tests to check DESTROY is only sent when neededGabriela Moldovan8 days1-25/+72
|
* proto: Allocate a real circ id in the circ reactor testsGabriela Moldovan8 days1-13/+47
| | | | | | | | | | | | | | | | | | | | | We need this because the channel reactor now only sends DESTROY for circuits that are still in the circ map (and we are about to test this behaviour, so we need the circuit map to actually have an entry for our test circuit). Initially, these tests were meant to test the circuit reactor in isolation, but they've gradually grown more complex, and now require a semi-working channel reactor. In the long run, I think I'd like to: * change the tests from `tor_proto::relay::reactor` to use a proper relay channel reactor as opposed to a `working_dummy_channel()`, and to initialize a circuit through the normal means, namely by sending a CREATE2 through the channel reactor (naturally, this "proper relay channel reactor" still wouldn't be connected to the network). These will test the integration between the channel and the circuit reactor, as well as the circuit reactor behaviour * add new, implementation-agnostic tests for the generic multi-reactor system. These will use a mock channel reactor
* proto: Update create handler tests to no longer expect DESTROYGabriela Moldovan8 days1-18/+6
| | | | | Now that we no longer respond to DESTROY by sending a DESTROY ourselves, these tests need to be updated.
* proto: s/client/next hop in test commentGabriela Moldovan8 days1-1/+1
| | | | This test simulates the *next hop* sending us a DESTROY.
* proto: Remove redundant headingGabriela Moldovan9 days1-2/+0
| | | | | | There is no `BackwardReactor` heading, because there isn't that much to say about it (it moves `RELAY` cells in the opposite direction, and rejects RELAY_EARLY and PADDING_NEGOTIATE).
* proto: Update table to mention all the other commands we handleGabriela Moldovan9 days1-2/+8
|
* proto: Be more specific about where the meta messages are handledGabriela Moldovan9 days1-14/+15
|
* proto: Say how forward DESTROY are handledGabriela Moldovan9 days1-1/+2
|
* proto: Clarify that "it" refers to the forward reactorGabriela Moldovan9 days1-1/+2
|
* proto: Update docs to clarify they apply to RELAY_EARLY tooGabriela Moldovan9 days1-3/+2
|
* proto: Update docs to say EXTEND2 is supportedGabriela Moldovan9 days1-5/+2
|
* proto: Update reactor docs to say TRUNCATE is unsupportedGabriela Moldovan9 days1-2/+3
|
* tor-proto: make `CreateRequestHandler` methods asyncSteven Engler2026-08-121-18/+26
|
* tor-proto: use `CgoRelayCrypto`/`Tor1RelayCrypto` aliasesSteven Engler2026-08-121-8/+7
|
* tor-proto: change `TryFrom<_> for HandshakeSubprotocols` to a dedicated ↵Steven Engler2026-08-121-1/+1
| | | | | | constructor Replaces `TryFrom<SubprotocolRequest> for HandshakeSubprotocols`.
* tor-proto: check the handshake type in the ntor testSteven Engler2026-08-121-8/+12
|
* tor-proto: implement the ntor-v3 handshakeSteven Engler2026-08-121-9/+199
|
* proto: Move comment to the right placeDavid Goulet2026-08-031-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-033-6/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-034-9/+9
| | | | | | | | | 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-034-17/+43
| | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | 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]>
* Merge branch 'mock-net' into 'main'David Goulet2026-07-301-20/+43
|\ | | | | | | | | tor-proto: Small improvements to circuit handshake tests See merge request tpo/core/arti!4254
| * tor-proto: reuse existing channels in ntor testSteven Engler2026-07-301-8/+5
| | | | | | | | | | Now that we read all of the cells from the connection inspector, we can reuse the existing channel objects.
| * tor-proto: extend circ handshake tests to close the circuitSteven Engler2026-07-301-2/+28
| |
| * tor-proto: rename some methods on test `ConnInspector`Steven Engler2026-07-301-6/+6
| |
| * tor-proto: reword some TODOsSteven Engler2026-07-301-2/+2
| | | | | | | | These TODOs are for client issues, not relay isues.
| * tor-proto: don't drop stream rx in testsSteven Engler2026-07-301-3/+3
| | | | | | | | Otherwise the new circuit gets closed immediately by the relay.
* | Merge branch 'create-fast' into 'main'opara2026-07-301-3/+2
|\ \ | |/ |/| | | | | 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-3/+2
| |
* | tor-proto: add unit tests for some circuit handshakesSteven Engler2026-07-291-0/+130
| |
* | tor-proto: add test-only `NoOpChannelProvider`Steven Engler2026-07-291-0/+22
| |
* | tor-proto: build crypt state after building hop settingsSteven Engler2026-07-271-10/+10
| | | | | | | | | | | | `HopSettings::from_handshake_params()` checks that the parameters are correct, so if there are invalid parameters we should fail early before we initialize the `CryptStatePair`.
* | tor-proto: move where we split 'crypt' in CREATE_FAST handshakeSteven Engler2026-07-271-2/+2
| | | | | | | | This is just to make ntor and CREATE_FAST handshakes consistent.
* | tor-proto: add some log messages after circuit handshakeSteven Engler2026-07-271-0/+5
|/
* tor-proto: add `HandshakeSubprotocols`Steven Engler2026-07-271-3/+9
| | | | | | 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-3/+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-70/+24
| | | | | | | | | | | | | | | ... 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: Remove misleading comment about CircuitIncomingStreamReceiverGabriela Moldovan2026-07-221-3/+0
|
* proto: Update CreateRequestHandler::new() docsGabriela Moldovan2026-07-221-1/+2
| | | | | As suggested in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437129
* proto: Reword CircuitIncomingStreamReceiver docs for clarityGabriela Moldovan2026-07-221-1/+2
| | | | Applies @opara's suggested rephrasing.
* proto: Return the incoming streams from the create handler (fmt)Gabriela Moldovan2026-07-221-8/+10
|
* proto: Return the incoming streams from the create handlerGabriela Moldovan2026-07-221-9/+56
| | | | | | | | | | | We need to return the "futures::Stream of Tor streams" from the CREATE handler, because these need to be handled from `arti-relay`, as per `doc/dev/notes/relay-streams.md` This commit is intentionally (slightly) misformatted to make reviewing a bit easier (the next commit will rustfmt everything). Part of #2612
* proto: Add newtype wrapper for incoming stream receiverGabriela Moldovan2026-07-221-0/+41
| | | | | The inner type is an eyesore, and doesn't really need to be exposed outside of tor-proto (we might even replace it at some point).