mirrors/arti.git/crates/tor-proto/src/channel/handshake.rs, branch main

proto: Use PeerInfo to log responder channel addr

2026-07-29T13:30:29Z

Inbound channel (as responder) don't have a ChannelMethod as they are not initiating the type of transport to use (PT vs Direct). It would result in a log line when receiving a channel request: DEBUG tor_proto::channel::handshake: Completed handshake without authentication to [? ] stream_id=Chan 2 This commit uses the `PeerInfo` which is wrapped in a `MaybeSensitive` and thus safe to log. Signed-off-by: David Goulet

tor-checkable: Rename `TimeBound::is_valid_at` to `check_valid_at`

2026-07-23T10:13:34Z

I find this names confusing. To my mind "is" implies a function returning `bool`.

tor-checkable: TimeBound: Make wrapped type an associated type

2026-07-23T10:13:34Z

It wouldn't make much sense for one concrete type to be unwrappable variously as different inner types.

tor-checkable: TimeBound: remove Error associated type

2026-07-23T10:13:34Z

This was always TimeValidityError. And we want to rely on that so we can do the validity checking more centrally.

proto: Return the incoming streams from the create handler

2026-07-22T12:12:10Z

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

Apply deferred rustfmt churn

2026-07-16T15:47:50Z

Use new TimeBound name throughout the tree

2026-07-16T15:47:50Z

proto: Pass the allowed incoming commands to CreateRequestHandler

2026-06-30T17:40:25Z

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: Pass an IncomingStreamRequestFilter factory to the create handler

2026-06-29T13:52:56Z

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 (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.

tor-proto: Remove a now-redundant .iter() in a call to iter_join

2026-06-11T12:27:27Z