aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
...
* proto: Reuse the RelayIds builder during the handshakeDavid Goulet2026-02-191-18/+11
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Pass PeerAddr at the channel handshake finish for initiatorsDavid Goulet2026-02-197-68/+35
| | | | | | | | | | Responder relay handshake requires the peer address at the very start as it sends its NETINFO right away. For initiators, we only need it during the finalization process which is when the NETINFO is sent and the Channel is created. Signed-off-by: David Goulet <[email protected]>
* proto: Use constructor for PeerInfo instead of BuilderDavid Goulet2026-02-192-18/+16
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove Default of PeerInfo/Addr and use const insteadDavid Goulet2026-02-194-31/+41
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Fix clippy errorsDavid Goulet2026-02-191-3/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Put a PeerInfo in ChannelDavid Goulet2026-02-193-3/+40
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use the PeerAddr accross channel handshakeDavid Goulet2026-02-198-69/+76
| | | | | | | This is a large change but it is basically using PeerAddr in the channel builder through the channel handshake code and into the Channel itself. Signed-off-by: David Goulet <[email protected]>
* proto: Add PeerInfo and PeerAddr in src/peer.rsDavid Goulet2026-02-192-0/+161
| | | | | | | | | | | | | | The plan is to create PeerInfo when we do a transport connect() which indicates the exact values that are being used for to connect to the peer. We'll then put this struct in the Channel so we can use it when picking the best channel in the ChanMgr. Unfortunately, the OwnedChanTarget has a confusing and even possibly wrong API from which we can't have guarantees. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused ChannelBuilderDavid Goulet2026-02-191-77/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* Merge branch 'circ-sync-view-streams' into 'main'gabi-2502026-02-169-117/+44
|\ | | | | | | | | | | | | proto: Replace circuit-scoped `CircSyncView` with per-hop alternative Closes #2351 See merge request tpo/core/arti!3680
| * proto: Remove unfinished sentence from docsGabriela Moldovan2026-02-161-2/+0
| |
| * proto: Update IncomingStreamRequestFilter docsGabriela Moldovan2026-02-161-2/+3
| | | | | | | | | | The `CircHopSyncView` is now the view of a hop, not of the whole circuit.
| * proto: Rename CircSyncView to CircHopSyncView (fmt)Gabriela Moldovan2026-02-161-1/+1
| |
| * proto: Rename CircSyncView to CircHopSyncViewGabriela Moldovan2026-02-166-23/+14
| | | | | | | | And update the docs
| * proto: Remove unused n_open_streams() functionsGabriela Moldovan2026-02-161-17/+0
| |
| * proto: Use CircSyncView in the new circuit reactorGabriela Moldovan2026-02-161-13/+7
| | | | | | | | | | Now that CircSyncView no longer needs to know the total number of streams, we can use it in the new per-hop stream reactor design.
| * proto: Replace circuit-scoped n_open_streams() with per-hop alternativeGabriela Moldovan2026-02-162-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `IncomingStreamRequestFilter`s, and `CircSyncView`s, by extension, are used both by old relay implementation and the new one for implementing an out-of-reactor way of deciding how to handle an incoming stream. In the new circuit reactor design, we have a separate stream reactor for each hop. Upon receiving an incoming stream, the stream reactor will need to build one of these `CircSyncView` objects, and then pass it to an externally-provided `IncomingStreamRequestFilter`. Before this change, `CircSyncView::n_open_streams()` returned the total number of open streams, which wouldn't have worked with the new reactor design, because the per-hop stream reactor doesn't have a global view of all the hops, so its `CircSyncView` can't return the total number of streams (at least not without message passing, or sharing state with the other stream reactors).
| * proto: Replace CircSyncView with previously client-only CircSyncViewGabriela Moldovan2026-02-165-72/+23
| | | | | | | | | | | | | | | | | | | | Note: this commit only contains the removal of the old `CircSyncView`, and it of course doens't compile. A future commit will replace the removed file with the `syncview.rs` from the client module. This change is split over two commits because it makes reviewing easier (`git mv`ing the new file over the old results in a confusing diff, because `git` refuses to show it as a move).
| * proto: Adjust visibility in client::reactor::CircSyncViewGabriela Moldovan2026-02-161-3/+3
| | | | | | | | | | This is in preparation for replacing the top-level `CircSyncView` with it.
| * proto: Use absolute path in CircHopList importGabriela Moldovan2026-02-161-1/+1
| | | | | | | | This file will be moved to the top-level `circuit` module soon.
| * proto: Rename ClientCircSyncView to CircSyncViewGabriela Moldovan2026-02-164-10/+7
| | | | | | | | | | This will soon replace `CircSyncView` wholesale. The preliminary renaming will make the future diffs easier to review.
| * proto: Add an accessor for the CircHopOutbound of a CircHopGabriela Moldovan2026-02-161-0/+5
| | | | | | | | This will soon be needed for building a `CircSyncView`.
* | Merge branch 'msrv-1.89' into 'main'Nick Mathewson2026-02-164-3/+4
|\ \ | |/ |/| | | | | Bump MSRV to 1.89 See merge request tpo/core/arti!3684
| * proto: Use is_multiple_of() as suggested by clippyGabriela Moldovan2026-02-163-3/+3
| |
| * Allow clippy::collapsible_if to triggerGabriela Moldovan2026-02-161-0/+1
| | | | | | | | | | | | | | | | | | `clippy::collapsible_if` started triggering after bumping the MSRV to 1.88. Since this triggers from a lot of places, and since there even are a couple of instances where we explicitly allow `clippy::collapsible_ifs`, I've opened #2342 for deciding what to do about it.
* | Merge branch 'relay-own-cert' into 'main'David Goulet2026-02-163-6/+20
|\ \ | |/ |/| | | | | relay: Pass our TLS cert to the responder verify process See merge request tpo/core/arti!3665
| * relay: Pass our TLS cert to the responder verify processDavid Goulet2026-02-123-6/+20
| | | | | | | | | | | | | | | | | | | | For the responder to build the authentication data, it needs its own certificate of the TLS handshake that it is responding to (as a TLS server). This resolves an important TODO(relay) in the code. Signed-off-by: David Goulet <[email protected]>
* | Merge branch 'early-relay' into 'main'gabi-2502026-02-127-132/+154
|\ \ | |/ |/| | | | | | | | | proto: Pass *all* cells to handle_forward_cell() Closes #2339 See merge request tpo/core/arti!3674
| * Revert "proto: Add a new ToRelayMsg util"Gabriela Moldovan2026-02-126-56/+2
| | | | | | | | | | | | | | | | | | | | This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17. Reverted because we no longer need to "peek" into the opaque `CircChanMsg` of a circuit reactor: now the implementation-dependent part of the reactor is in charge of handling the channel messages, and extracting `Relay` objects out of RELAY/RELAY_EARLY cells, which then get processed in the base reactor.
| * proto: Remove unused function in relay FWD reactorGabriela Moldovan2026-02-121-7/+1
| |
| * proto: Move decode_relay_cell() out of ForwardHandlerGabriela Moldovan2026-02-122-43/+36
| | | | | | | | | | | | | | | | This doesn't need to be part of the `ForwardHandler` trait anymore, because the base reactor no longer calls it directly (instead implementations are supposed to handle it internally). No functional changes here, just code motion.
| * proto: Forbid EXTEND2 from RELAY cellsGabriela Moldovan2026-02-122-2/+11
| | | | | | | | Closes #2339
| * proto: Pass the early flag to handle_relay_msg() (fmt)Gabriela Moldovan2026-02-121-1/+3
| |
| * proto: Pass the early flag to handle_relay_msg()Gabriela Moldovan2026-02-121-3/+5
| | | | | | | | | | Needed because some messages are handled differently depending on the cell type they originated from (RELAY vs RELAY_EARLY).
| * proto: Return a protocol error if we get too many RELAY_EARLYGabriela Moldovan2026-02-121-1/+20
| |
| * proto: Overhaul forward cell handlingGabriela Moldovan2026-02-122-21/+74
| | | | | | | | | | | | | | | | | | | | | | This pushes the RELAY/REALY_EARLY handling inside `handle_forward_cell()`, which now decodes the relay cells and * handles them internally, if they are unrecognized (`handle_unrecognized_cell()`), or * returns them back to the base reactor if they are recognized (RELAY and RELAY_EARLY cells are handled the same way by the base reactor)
| * proto: Give handle_forward_cell() a handle to the hopmgrGabriela Moldovan2026-02-122-4/+11
| | | | | | | | | | Soon this function will be in charge of decoding the cell too, so it will need a handle to the `HopMgr` (see `decode_relay_cell()`)
| * proto: Pass *all* cells to handle_forward_cell()Gabriela Moldovan2026-02-121-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the implementation-dependent `handle_forward_cell()` handled all forward cells *except* for RELAY cells, which were handled in the generic base reactor. This changes the implementation to pass *all* cells, including RELAY cells, to `handle_forward_cell()` too. This is needed because both RELAY and RELAY_EARLY cells need to be handled very similarly: both can be either recognized or unrecognized, with unrecognized cells being handled by the implementation-dependent code, and the recognized ones being sent to the base reactor for handling. A future commit will update `handle_forward_cell()` to extract `Relay` object out of RELAY/RELAY_EARLY cells, and return it back to the base reactor for handling.
* | Merge branch 'channel-canonical' into 'main'David Goulet2026-02-128-47/+173
|\ \ | |/ |/| | | | | Implement channel canonicity See merge request tpo/core/arti!3668
| * proto: Client channel need to consider PT for the targetDavid Goulet2026-02-121-6/+21
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
| * chan: Use Canonicity when choosing a channelDavid Goulet2026-02-121-3/+10
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
| * proto: Enforce that channel method as unique SocketAddrDavid Goulet2026-02-123-28/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | During the channel handshake, we require the peer IP address for the canonicity check which requires the exact peer IP we are connected to. This commit adds a function that enforces this requirement on a ChannelMethod so anything else results in an error. It is to basically have stronger guarantee on the channel method we use in the handshake. Signed-off-by: David Goulet <[email protected]>
| * proto: Channel finish() now handles canonicityDavid Goulet2026-02-128-32/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | All handshake pass the NETINFO cell, the advertised addresses (if any) and the peer address in order to build the Canonicity and build the channel with it. In order to pull this off, the "my_addrs" were added to several object along the NETINFO cell. We also pass the channel method when connecting (initiator) to a relay as we need this for this canonicity build. Signed-off-by: David Goulet <[email protected]>
| * proto: Implement a Canonicity structDavid Goulet2026-02-121-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This struct will be put in a Channel and derived from the received NETINFO cell. This follows the C-tor implementation for which we have two indicator of canonicity: 1. Peer is canonical: the address they advertise in the NETINFO cell matches the one we see on the TCP connection. 2. Canonical to peer: the peer sees us as canonical. Those flag will get used to select "the best" channel. Signed-off-by: David Goulet <[email protected]>
* | proto: Return internal error on TRUNCATEGabriela Moldovan2026-02-121-1/+1
|/ | | | | | | | This is not yet implemented, so we should just return an error for now (`todo!()` will cause a panic, shutting down the thread the reactor is running on. We don't want this happening when we start manually testing our WIP impl, because depending on which thread it happens on, it can make the entire relay process unusable).
* proto: Add big TODO about flushingGabriela Moldovan2026-02-111-0/+13
|
* proto: Implement validate_backward_cell() for relaysGabriela Moldovan2026-02-111-3/+34
| | | | Closes #2345
* proto: Start forwarding cells in the backward reactorGabriela Moldovan2026-02-111-4/+11
|
* proto: Extend BWD handler with a backward cell handling functionGabriela Moldovan2026-02-112-1/+26
| | | | This will tell the base `BackwardReactor` how to handle the cell.
* proto: Relay responder channel allow to be non_exhaustiveDavid Goulet2026-02-091-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-28 12:22:58 +0000