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

tor-hsservice: Suppress false-positive clippy::useless_concat.

2025-07-07T16:03:11Z

Temporarily suppress mismatched_lifetime_syntaxes.

2025-07-07T15:50:04Z

See #2060.

hspow: Add a clippy::cognitive_complexity exception

2025-07-03T18:49:04Z

hsservice: Stop using HopNum and use TargetHop

2025-06-26T14:18:30Z

This requires some changes to the tor-proto crate to handle the inbound TargetHop from the HS subsystem and then resolve it into a HopNum for a single circuit. It is expected that this will change again with Conflux to only use HopLocation internally in a Tunnel and then use HopNum into a Circuit. Signed-off-by: David Goulet

proto: Make send_raw_msg() use a TargetHop

2025-06-26T14:18:30Z

In order for this to work, a last_target_hop() function is added to ClientCirc in order to return a precise hop location as a TargetHop of the last hop. This is needed because in the HS subsystem, we need such value in order to get a location on the last physical hop before adding the virtual hop. The RDV1 cell is sent to that last target hop while the allow_stream_request() is done on the virtual target hop. Signed-off-by: David Goulet

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

proto: Move NegotiatedHopSettings to a higher level

2025-06-10T15:52:28Z

We will construct this object based on the circuit parameters _and_ on the target's supported protocol versions, so we need to do so when we have both pieces of info.

*: 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-hsservice: Fix typo.

2025-05-27T18:05:01Z