mirrors/arti.git/crates/tor-hsservice/src/ipt_establish.rs, branch arti-v1.4.5

hs: Remove the use of HopNum and instead use TargetHop

2025-06-26T14:18:30Z

This is in the spirit of making everything going inbound the tor-proto crate to use a TargetHop. This becomes much easier for the HS subsystem as it only uses the last hop for its conversation and setup. Signed-off-by: David Goulet

proto: Add a control command to get the binding key

2025-06-26T14:18:30Z

This allows us to use TargetHop instead of HopNum but also to get one step closer to not depend on a mutable state. We prefer resolving a TargetHop within the Reactor object in order to use the circuit list instead of the MutableState path. The HS service subsystem is modified to use this modified function that is now async and uses a TargetHop. Signed-off-by: David Goulet

*: suppress cognitive_complexity warnings from nightly

2025-05-29T14:21:17Z

Apparently clippy nightly is better (or worse?) about detecting complex functions than before, so I'm suppressing these warnings where they occur. I have mixed feelings about these warnings: On the plus side, they really do help to detect functions that are twistier than they need to be. On the minus side, they get confused by tracing macros, and the "allows" do pile up. But on the plus side, those "allows" do provide a way to find functions that need to be refactored, and they are never uglier than the functions they decorate.

tor-proto: Update the TunnelMutableState when a circuit is removed.

2025-05-15T16:33:33Z

This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become fallible (we can't unwrap the result, because when a circuit is closed, its state gets removed from the `TunnelSharedState`, but its `ClientCirc` handle continues to exist, so any attempt to retrieve the state will result in an `Err`).

Merge branch 'named_protovers' into 'main'

2025-03-20T17:10:03Z

protover: Add support for subprotocol version mnemonics. Closes #1891 See merge request tpo/core/arti!2854

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`

Use named subprotocol versions throughout arti.

2025-03-12T14:47:05Z

tor-hsservice: Make ReplayLog generic.

2025-02-10T15:40:18Z

proto: Remove ConversationInHandler

2025-02-04T16:08:43Z

It is unused but most importantly it allows any RELAY cell to be sent from anywhere in the code which is really not desirable because it is skipping congestion control. It also allows us to remove the `control_tx` from the reactor which is one less channel to track/understand/think about. This opens up the door to all sorts of problems especially side channel that can be exploited if we are not careful. We can always bring this back if we need it but for now, it is unused and allows us to remove the `CtrlMsg::SendRelayCell` control message. No code behavior change. Signed-off-by: David Goulet

tor-proto: Rewrite circuit reactor run_once() loop to use select!.

2025-01-29T14:34:58Z

This rewrites the circuit reactor main loop to use `select_biased!` to poll multiple futures simultaneously. The new `run_once()`, like the old, first waits for an initial `CtrlMsg::Create`. Then, it uses a `select_biased!` to poll the `chan_sender` sink and shutdown channel for readiness. When the channel sink is ready, we poll the `control` and `input` channels like before, as well as the new `ready_streams` `Stream` (`ready_streams` is a `futures::Stream` that replaces the previous `send_outbound()` function). Most of the implementation remains unchanged, except the `handle_input`, `handle_cell` and `handle_control` functions no longer send anything on the `chan_sender` channel. Instead, they may do some (synchronous) processing, and send instructions for the remaining work that needs to be done (for example, for writing the cell to the `chan_sender` channel). These instructions are handled at the end of `run_once()`, and are encoded in the `RunOnceCmdInner` enum. What this change does **not** do: * the control channel *still* bypasses congestion control. We could fix this by making the various reactor functions send the `RunOnceCmdInner` commands to `run_once()` via a channel (instead of returning them). This would enable the reactor to stop reading the commands (except for handle `Sendme`, which would be handled separately) if it's blocked on congestion control.