summaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | 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-1214-66/+276
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | 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-125-6/+59
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
| * | | | proto: Enforce that channel method as unique SocketAddrDavid Goulet2026-02-124-28/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | | | chanmgr: Use the actual channel target used on connect()David Goulet2026-02-121-16/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When connecting, we pass an OwnedChanTarget that can contain a list of IPs of the relay we want to connect to. The connect() picks one and return the actual OwnedChanTarget used as in the real IP address we are using. From that point on, we must only use that as the channel canonicity requires to check against the IP we believe we are connected to. This also is much better to use for error handling considering the error is on the actual channel target, not the hypothetical one. Signed-off-by: David Goulet <[email protected]>
| * | | | proto: Channel finish() now handles canonicityDavid Goulet2026-02-129-32/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-122-1/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | | Merge branch 'avoid-truncate-panic' into 'main'David Goulet2026-02-121-1/+1
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | proto: Return internal error on TRUNCATE See merge request tpo/core/arti!3675
| * | | | | 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).
* | | | | tor-chanmgr: update comment in `open_channel_is_allowed()`Steven Engler2026-02-111-2/+10
| | | | |
* | | | | tor-chanmgr: channel selection functions take a `HasAddrs`Steven Engler2026-02-111-18/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We will want our channel selection functions (`open_channel_is_allowed`, `pending_channel_maybe_allowed`, and `choose_best_channel`) to inspect the requested target addresses in the future (see their TODOs), so these functions need to take a `HasAddrs` to get those addresses.
* | | | | tor-chanmgr: add `HasAddrs` bound to `AbstractChannelFactory::BuildSpec`Steven Engler2026-02-112-19/+31
|/ / / / | | | | | | | | | | | | | | | | This will be needed later so that our channel selection functions can take a `HasAddrs`.
* | | | Merge branch 'relay-backward' into 'main'gabi-2502026-02-112-7/+83
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | proto: Handle backward cells in the reactor Closes #2345 See merge request tpo/core/arti!3666
| * | | | 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.
* | | | arti: Enable tor-hsservice/onion-service-cli-extra when needed (fmt)Gabriela Moldovan2026-02-111-1/+7
| | | |
* | | | arti: Enable tor-hsservice/onion-service-cli-extra when neededGabriela Moldovan2026-02-111-1/+1
|/ / / | | | | | | | | | | | | | | | | | | Without this change `arti` fails to compile with the `onion-service-cli` and `onion-service-service` features enabled. Closes #2347
* | | relay: Fix tor-chanmgr and tor-proto cargo featuresDavid Goulet2026-02-092-3/+3
| | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | proto: Relay responder channel allow to be non_exhaustiveDavid Goulet2026-02-092-2/+1
| | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | proto: Add x509 tor-cert featureDavid Goulet2026-02-091-1/+1
| | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | chanmgr: Fix the outbound_chan_type() to not be based on relay featureDavid Goulet2026-02-091-10/+4
| | | | | | | | | | | | | | | | | | | | | A client can have the relay feature enabled. The presence of "identities" is what dictates if we are a relay or not. Signed-off-by: David Goulet <[email protected]>
* | | chanmgr: Gate relay only functionDavid Goulet2026-02-092-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Also, allow the `ChanMgr::runtime` to be unused as client don't use it yet but might one day. Simpler this way than feature gating it for relay only. Signed-off-by: David Goulet <[email protected]>
* | | chanmgr: Add inbound open channel to our listDavid Goulet2026-02-092-9/+26
| | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | chanmgr: Build channel/reactor on incoming connectionsDavid Goulet2026-02-091-6/+74
| | | | | | | | | | | | | | | | | | | | | | | | Implement the accept_from_transport() in the ChanBuilder. This returns a `Channel` and spawns a reactor. Signed-off-by: David Goulet <[email protected]>
* | | proto: Publicly re-export MaybeVerifiableRelayResponderChannelDavid Goulet2026-02-093-0/+5
| | | | | | | | | | | | | | | This type is needed in the tor-chanmgr crate in order to decide to verify or not the underlying relay channel.
* | | relay: Add a TLS acceptor in the ChanBuilderDavid Goulet2026-02-0910-50/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires the `TlsKeyAndCert` so be passed on the TLS acceptor settings. We assume that `RelayIdentities` has this information. The ChanBuilder::new() was getting a bit too convoluted and feature gated to instead we introduce new_client() and new_relay() and remove the need for `with_identities()`. Because of this, the ChanMgr::new() now returns a `Result<>`. Related to #1597 Signed-off-by: David Goulet <[email protected]>
* | | relay: Enable "tls-server" feature flag for tor-rtcompatDavid Goulet2026-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | This makes it that we can get a server TLS acceptor provider which we need for incoming connections. Signed-off-by: David Goulet <[email protected]>
* | | Merge branch 'cargo-metadata-all-features' into 'main'Nick Mathewson2026-02-0924-0/+72
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Set package.metadata.docs.rs.all-features to true for all crates Closes #2307 See merge request tpo/core/arti!3656
| * | | Set package.metadata.docs.rs.all-features to true for all cratesNiel Duysters2026-02-0924-0/+72
| | | | | | | | | | | | | | | | Makes docs.rs also document types behind optional feature flags.
* | | | Merge branch 'extend2' into 'main'gabi-2502026-02-0913-234/+477
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | proto: Start handling EXTEND2 in the relay reactor Closes #1447 See merge request tpo/core/arti!3648
| * | | | proto: Say why it's okay not to have timeouts in a couple of placesGabriela Moldovan2026-02-091-0/+6
| | | | |
| * | | | proto: Remove the EXTEND2 timeout for nowGabriela Moldovan2026-02-091-26/+11
| | | | | | | | | | | | | | | | | | | | | | | | | See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3648#note_3339863
| * | | | proto: Reject EXTEND2 cells even if we already have an extension in progressGabriela Moldovan2026-02-091-1/+12
| | | | |
| * | | | proto: Ensure DESTROY gets sent on circuit dropGabriela Moldovan2026-02-052-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements this part of the spec: ``` To tear down a circuit completely, a relay or client sends a DESTROY cell to the adjacent nodes on that circuit, using the appropriate direction’s circID. ```
| * | | | proto: Make handle_extend2() synchronousGabriela Moldovan2026-02-051-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This doesn't need to be async, as it delegates the handling to a background task.
| * | | | proto: Implement EXTEND2 handlingGabriela Moldovan2026-02-052-152/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To handle EXTEND2, the relay `ForwardHandler` impl spawns a background task, which reports back the result via the `CircEvent` MPSC stream. This stream is polled from the `ForwardReactor` main loop, and each `CircEvent` is passed back to `ForwardHandler::handle_event()` for handling.
| * | | | proto: Move CREATE helpers to a shared moduleGabriela Moldovan2026-02-053-6/+6
| | | | | | | | | | | | | | | | | | | | These will be used by the relay code too (for circuit extension).
| * | | | proto: Reword an error message for clarityGabriela Moldovan2026-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | Users reading the log won't necessarily know what a "forward channel" is.
| * | | | proto: Add BWD command for receiving newly launched outbound channelsGabriela Moldovan2026-02-051-0/+36
| | | | |
| * | | | proto: Give handle_meta_msg() a handle to the runtimeGabriela Moldovan2026-02-053-3/+10
| | | | |
| * | | | proto: Add an implementation-dependent reactor event streamGabriela Moldovan2026-02-054-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | This will enable us to obtain implementation-dependent asynchronous events (such as the outcome of an extend handshake).
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 19:40:56 +0000