aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-091-2/+10
| | | | | | | | | | | | | | | 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]>
* 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).
* proto: Add new LinkspecDecodeErr kindGabriela Moldovan2026-02-051-0/+15
| | | | | | This will be needed by relays, for wrapping tor_linkspec decode errors (which can happen if the link specifiers in the EXTEND2 cell can't be converted to a channel target).
* proto: Make chan_provider an ArcGabriela Moldovan2026-02-052-3/+4
| | | | To match the `ChannelProvider::get_or_launch()` function signature.
* proto: Pass the unique id to Forward handlerGabriela Moldovan2026-02-052-1/+6
| | | | | | We need the unique_id here, because the Forward handler will soon start using the `ChannelProvider::get_or_launch()` to launch outbound channels, which takes the reactor unique_id as an argument.
* proto: Move channel provider out of the generic reactorGabriela Moldovan2026-02-054-72/+18
| | | | | | The channel provider is relay-specific, so I am moving it to the relay `ForwardHandler` implementation. This enables us to get rid of some of the feature gating from the generic reactor.
* proto: Add Channel function for launching outbound relay circuitsGabriela Moldovan2026-02-051-0/+47
| | | | This is currently very similar to its client counterpart.
* proto: Make inner part of OutboundChanSender pub(crate)Gabriela Moldovan2026-02-051-1/+1
| | | | We will need the ability to build one from within tor-proto.
* proto: Fix misleading SendRelayMsg docsGabriela Moldovan2026-02-051-1/+1
| | | | This was leftover from back when this command was only for Sendmes.
* proto: Make ChannelProvider::get_or_launch() synchronousGabriela Moldovan2026-02-051-1/+1
| | | | This just removes an unnecessary `async`.
* proto: Add missing clock_skew() to unverified channelsDavid Goulet2026-02-043-8/+15
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused traits after type refactoringDavid Goulet2026-02-041-73/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Make channel client to use a specific typeDavid Goulet2026-02-041-38/+43
| | | | | | Remove the use of traits, the caller will handle the specific type. Signed-off-by: David Goulet <[email protected]>
* proto: Relay channel code cleanupDavid Goulet2026-02-041-323/+4
| | | | | | No need for these types, we've replaced them with more specific types. Signed-off-by: David Goulet <[email protected]>
* proto: Introduce new relay responder channel typesDavid Goulet2026-02-043-20/+211
| | | | | | | | | | Add the unverified, verified, non verifiable flavor types of a responder channel. This follow on the previous commit to use the type system for stronger guarantees. Signed-off-by: David Goulet <[email protected]>
* proto: Introduce new relay initiator channel typesDavid Goulet2026-02-043-4/+188
| | | | | | | | | | | | | | | | | | | This commit adds the Unverified and Verified flavor of a relay channel specific to an initiator. We decided to use the type system for safety and avoid patterns like: "if chan.is_initiator() {...} else {...}" This allows us also to not duplicate code between initiator and responder code. The downside is that we expose these types outside of tor-proto meaning the caller needs to feature gate the usage of these types with the "relay" flag. Small price to pay for strong guarantees with the type system. Signed-off-by: David Goulet <[email protected]>
* proto: Move the ChannelAuthenticationData::build() function into the object ↵David Goulet2026-02-041-0/+85
| | | | | | | | | itself Previous function "build_auth_data()" is still around but will be removed in the upcoming commits. Signed-off-by: David Goulet <[email protected]>
* proto: Remove assumption that we are a relay from BWD docGabriela Moldovan2026-02-041-1/+1
| | | | This was leftover from back when the BWD was a relay-specific type.
* proto: Replace SendSendme with a more general-purpose command (fmt)Gabriela Moldovan2026-02-041-5/+4
|
* proto: Replace SendSendme with a more general-purpose commandGabriela Moldovan2026-02-043-13/+14
| | | | | This will soon be used for instructing the BWD to send other types of messages too.
* proto: Replace send_sendme() with general-purpose functionGabriela Moldovan2026-02-041-8/+12
| | | | | | | The backward reactor will soon need the ability to send other types of relay messages too: it will soon need the ability to respond to EXTEND2 by sending back an EXTENDED2, so I am preemptively making this function more general so we can reuse it.
* proto: Allow unused async in WIP reactor codeGabriela Moldovan2026-01-291-0/+2
| | | | This will need to become async soon.
* proto: Remove unused async from relay reactorGabriela Moldovan2026-01-291-1/+1
| | | | Fixes a clippy warning
* proto: Document that the hop list is shared with the BWDGabriela Moldovan2026-01-291-0/+11
|
* proto: Rename the FWD -> BWD channelGabriela Moldovan2026-01-293-18/+18
| | | | | | | In the backward reactor, we call this the `forward_reactor_rx` (because it receives commands from the foward reactor), and in the forward reactor we call it `backward_reactor_tx` (because it sends commands to the backward reactor).
* proto: Rename chan senders and sinks for clarityGabriela Moldovan2026-01-294-43/+43
| | | | | | | | | | We settled on * `inbound_chan{tx, rx}`, for the inbound channel (the channel towards the guard, if we are a client, or towards the client if we are a relay) * `outbound_chan{tx, rx}`, for the outbound channel (the channel towards the exit, if we are a middle relay)
* proto: Update misleading comment about cmd_rxGabriela Moldovan2026-01-291-1/+1
|
* proto: Allow CircSynvView::new_relay() to be unusedGabriela Moldovan2026-01-291-0/+1
| | | | | This will change significantly in the near future, or disappear entirely.
* proto: Replace relay reactor with new generic reactorGabriela Moldovan2026-01-294-1747/+336
|
* proto: Add a new, implementation-agnostic circuit reactorGabriela Moldovan2026-01-297-5/+3063
|
* proto: Avoid locking in CircHopOutbound::ccontrol()Gabriela Moldovan2026-01-295-15/+37
| | | | | | | | This is just because the generic reactor will soon need a clone of the CC object, so I am preemptively making this function return a ref to the underlying `Arc` instead. Technically, it would've been fine to just kept this method and add a separate one returning `&Arc<Mutex<..>>`, but I'd prefer keeping the API small.
* proto: s/Forward/ForwardSender for clarityGabriela Moldovan2026-01-291-3/+3
| | | | | This renaming is needed because I will soon introduce a new `Forward` struct, with a completely different purpose.
* proto: Rip CC state out of CircHopInboundGabriela Moldovan2026-01-294-24/+6
| | | | | | Soon it won't need be needed here any more. I'm removing it, because having redundant handles to the CC state makes it difficult to see exactly where it's being used from.
* proto: Factor ReactorResultChannel into the shared reactor moduleGabriela Moldovan2026-01-292-3/+6
| | | | This is not just for clients!
* proto: Add a new module for the generic circuit reactorGabriela Moldovan2026-01-292-0/+10
| | | | Currently empty, will be fleshed out in a future commit.
* proto; Factor HOPS constant out of maybenot_paddingGabriela Moldovan2026-01-292-3/+4
| | | | I am about to use this in other places too.
* proto: Move padding_disposition() to the shared padding moduleGabriela Moldovan2026-01-292-54/+74
|
* proto: Move CircPaddingDisposition to a new moduleGabriela Moldovan2026-01-293-13/+18
| | | | Relays will need to use it too.
* proto: Add a new ToRelayMsg utilGabriela Moldovan2026-01-294-0/+51
| | | | | | | | | This will be used in a future commit, inside the new generic circuit reactor. We need it because RELAY cells are handled very similarly, so we need some way of finding out if a given generic chancell is actually a RELAY cell that we can handle in an implementation-agnostic way.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-28 20:28:49 +0000