mirrors/arti.git/crates/tor-proto/src/client/channel/handshake.rs, branch arti-v2.2.0

tor-proto: Port to web-time-compat

2026-03-26T19:20:16Z

tor-proto: fix the relay initiator's SLOG digest

2026-03-19T20:31:09Z

proto: Set the link protocol outside the recv VERSIONS helper

2026-03-19T20:31:09Z

It used to work for an initiator to set the link protocol once a VERSIONS is received because initiator send their VERSIONS before. This failed with responders because a responder channel sends their VERSIONS after receiving one from the initiator. This reverse logic means that the channel cell handler was transitionned to the Handshake state before a responder was able to send a VERSIONS cell leading to a failure because VERSIONS cell aren't allowed at the Handshake state. To fix this, the send/recv or recv/send is now explicit per channel type and once this is done and successful, the link protocol is set. A `set_link_protocol()` is added to the ChannelBaseHandshake trait so it can be used to set the cell handler. Signed-off-by: David Goulet

proto: New UnverifiedInitiatorChannel

2026-03-19T20:31:09Z

Both client and relay specialized channel now use it as their inner base channel so they can use the same common verify() function since it is the same validation for both. Signed-off-by: David Goulet

proto: Move cert validation per specialized channel

2026-03-19T20:31:08Z

Remove the last part from check_internal() that is specific to an initiator channel. At this commit, all three specialized channel do the verify process within their own verify() function. The client and relay initiator both look at the TLS cert (code duplication unfortunately). And the relay responder looks at the LINK_AUTH cert extracting the peer KP_link_ed key for validation. The CERTS cell is removed from UnverifiedChannel as it is now only useful within the verification process which is now specialized. A series of TODO(relay) is added to point out the current problem and how to fix them. The next step is to create an UnverifiedInitiatorChannel that will hold the verity_tls_cert() function and peer cert information which is only relevant to an initiator. This will remove code duplication. Signed-off-by: David Goulet

proto: Use RelayIds in a VerifiedChannel

2026-03-19T20:31:08Z

In order to pull this off, make UnverifiedChannel::check_relay_identities() to return a RelayIds that it builds after checking if they match the peer we were expecting. This part is moved in this commit so once check_relay_identities() returns, we are certain of the relay identity validity on both "it identified properly" and "it is the right expected relay". This makes it that the check_relay_identities() returns the RelayIds, the signing key and the RSA id digest (which is needed for authentication later). Signed-off-by: David Goulet

tor-proto: remove `is_expecting_auth_challenge()`

2026-03-03T19:57:04Z

The responder always sends an AUTH_CHALLENGE cell.

safelog: Rename MaybeSensitive::hidden/visible()

2026-03-03T15:51:33Z

Rename them to respectively sensitive() and not_sensitive(). Signed-off-by: David Goulet

proto: Channel handshake minor cleanup

2026-03-03T15:51:33Z

To make the code a bit better here. Also, at this commit, the UnverifiedChannel::finish() and VerifiedChannel::finish() are basically the exact same. A refactoring to use a finish() helper would work nicely. Signed-off-by: David Goulet

proto: Setup the channel PeerInfo in the specialized finish()

2026-03-03T15:51:33Z

Every specific types know if the peer is sensitive or not so now the finish() of each of these channel types builds the right PeerInfo with MaybeSensitive. This is passed on the Channel so from that point on, the Channel will never leak peer data in the logs. Signed-off-by: David Goulet