summaryrefslogtreecommitdiff
path: root/crates/tor-hsclient/src/connect.rs
Commit message (Collapse)AuthorAgeFilesLines
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-281-12/+12
| | | | | | | This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.
* proto: Move the `stream` module under `client` (breaking).Gabriela Moldovan2025-08-181-1/+1
| | | | | | | | | | | | The `stream` module is client-specific, for the most part, so I am moving it under `client`. Later on, we will factor out the parts that can be shared with the relay implementation. Note: this is a breaking change as the deleted `stream` module was `pub`. We could've kept the module and reexported from it the public types from `tor_proto::client::stream`, but I think it's better to have this `client` namespacing, because it makes the separation between the client and relay parts clearer.
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-11/+11
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* tunnel: Implement start_conversation() for all tunnel typesDavid Goulet2025-08-051-3/+4
| | | | | | | | | | The BaseTunnel now has a start_conversation() which takes a TargetHop meaning it can be used with a multi path tunnel. The Conversation object has been moved into the tunnel namespace out of the circuit one. Signed-off-by: David Goulet <[email protected]>
* hs: Use the new Tunnel interface for onion serviceDavid Goulet2025-08-051-97/+204
|
* Use new DisplayRedacted/DebugRedacted code for HsId.Nick Mathewson2025-07-311-3/+3
| | | | Closes #2012.
* hs*: Define some HsDesc errors as _suspicious_.Nick Mathewson2025-07-101-8/+21
| | | | | These errors are suspicious as hsdir inflation attacks, in the context of prop360.
* hs*: Include SourceInfo when making HsDesc requests.Nick Mathewson2025-07-101-1/+18
|
* hs: Remove the use of HopNum and instead use TargetHopDavid Goulet2025-06-261-2/+2
| | | | | | | | | | 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 <[email protected]>
* proto: Move NegotiatedHopSettings to a higher levelNick Mathewson2025-06-101-1/+10
| | | | | | 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 nightlyNick Mathewson2025-05-291-0/+2
| | | | | | | | | | | | | 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.
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-2/+2
| | | | - The Rng::gen() functions have been renamed to Rng::random().
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-1/+1
| | | | - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
* tor-rtmock: allow-Decorate every use of MockSleepProviderIan Jackson2025-03-061-0/+2
| | | | | | | MockSleepProvider and MockSleepRuntime have been declared deprecated by the docs for some time. We're about to mark them `#[deprecated]`. This commit has been split out for clarity of review.
* hsclient: Include rsa_id in debugClara Engler2025-03-041-1/+2
| | | | | | | This commit adds the RSA ID of a relay into a debug statement, as found in other places in the code. It mostly serves the purpose that the Ed25519 ID in itself is rather inconvenient, as metrics.torproject.org only allows querying from the RSA ID.
* proto: Remove ConversationInHandlerDavid Goulet2025-02-041-5/+1
| | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* tor-proto: Rewrite circuit reactor run_once() loop to use select!.Gabriela Moldovan2025-01-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* circmgr: Remove the CircParameters build .expect()David Goulet2025-01-161-1/+2
| | | | | | Instead, return an error and make all call site handle it. Signed-off-by: David Goulet <[email protected]>
* circ: Specialize the circparams from netparams functionDavid Goulet2025-01-161-3/+2
| | | | | | | | | | | | | | | Congestion control parameters have specific values depending on the circuit type. Instead of using a CircuitType, which is removed in this commit, specialize the function in this case onion and exit. This allows us to get rid of CircuitType and solely use TargetCircUsage instead. At this commit, we use .expect() on the Builder. Future commit will remove this to return a Result in case of failure. Worth noting that we don't expect one. Signed-off-by: David Goulet <[email protected]>
* circmgr: Modify CircParameters for congestion controlDavid Goulet2025-01-161-2/+3
| | | | | | | | | | | | | | The congestion control parameters are created from the consensus parameters (netparams) and then put into the CircParameters object that is then passed down the tor-proto crate. Because different parameters are selected depending on the circuit type (onion vs exit vs sbws), a CircuitType enum is introduced for the sole purpose of being used to select the right parameters. Related #534 Signed-off-by: David Goulet <[email protected]>
* TimerangeBound: Stop using std::ops::Bound.Wesley Aptekar-Cassels2024-11-251-7/+3
| | | | Fixes: #1691
* Use HsPowClient.Wesley Aptekar-Cassels2024-10-091-1/+2
| | | | | | | The fully qualified name earlier was helpful when this was optional, but now that it's required let's stick it with the other 'use crate'. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* hs-pow: Refactor to prefer stub types rather than cfg sprawl.Wesley Aptekar-Cassels2024-10-091-6/+1
| | | | | | | | | | | | | | | | | | | | | | In this design, the thin multiplexing layer between PoW types is always available when onion services are in use, but the specific pow schemes (and their dependency libraries) are gated by crate features everywhere. There are now no new cfg() gates. When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines into an empty type (so clients know a PoW scheme exists that might be supported if they were configured differently). We currently don't save the contents of unknown hsdesc items. On the relaycell side, the hs ext module already sets a strong precedent for keeping unrecognized data as a byte vec, and it doesn't provide a good way to signal soft parse errors like unrecognized optional extensions. There, the `v1` type is completely optional, and services lacking a pow scheme suggested by a client would see one of these 'unrecognized' blobs. This isn't necessarily helpful but it fits the rest of the design. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-hspow: Big refactor, dissolve this crateWesley Aptekar-Cassels2024-10-091-8/+9
| | | | | | | | | | | | | | | | | My previous strategy here was to try and centralize hspow in one crate, writing it like a self-contained feature. That introduced friction in the data types, prompting the use of simplistic types at the netdoc/cell layers and full-featured types in the optional modules. This changes tactics, dissolving the low-level parts of tor-hspow into tor-hscrypto and the high-level parts into hsclient/hsservice. Full featured types are used everywhere now, but the tradeoff is that compile-time configurability is a lot more pervasive. Anything that knows about PoW types at all needs to be fully configured out. I took this opportunity to try a more complete set of crate features, allowing users to configure individual PoW schemes. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* First pass at implementing onion proof-of-work clientWesley Aptekar-Cassels2024-10-091-4/+33
| | | | | | | | This adds a module to tor-hspow for version-independent client logic. The entire module and its invocations are disabled unless the new "hs-pow" compile time feature is set. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-cell: Support encoding proofs-of-work in intro_payloadWesley Aptekar-Cassels2024-10-091-1/+1
| | | | | | | | | Like parameters, PoW solutions are versioned to account for multiple algorithms over time. A single solution of a specific version may accompany an INTRO1/2 as part of the encrypted extensions section. Its encoding may depend on the version. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* Remove hard tabs in the one file that has them.Ian Jackson2024-10-021-2/+2
|
* Fix a couple of lifetime warnings from nightly.Nick Mathewson2024-10-011-2/+2
| | | | | | | | | Nightly rustdoc, under some circumstances, issues a warning when you have an elided lifetime that matches a lifetime with a name. (It would prefer that you name the lifetime explicitly.) This does not change the actual lifetime of anything; it only makes some formerly elided lifetimes explicit.
* rtcompat: Add an extension trait for building modified RuntimesNick Mathewson2024-09-241-9/+5
| | | | | | | With this extension trait, we no longer need to construct `CompoundRuntime` directly outside of tor-rtcompat. This in turn will make it a little less painful when we have to add more generics to CompoundRuntime.
* Merge branch 'refactor_stream_crypto_init' into 'main'Nick Mathewson2024-03-261-4/+2
|\ | | | | | | | | Refactor the logic for constructing crypt layers. See merge request tpo/core/arti!2048
| * Refactor the logic for constructing crypt layers.Nick Mathewson2024-03-261-4/+2
| | | | | | | | | | | | | | | | | | | | | | The key insights here are: - That relay cell format and crypto protocols aren't orthogonal: Once we have GCO, it will require V1. - That we only need the actual functions for layer construction to be generic; we don't need to proliferate generic parameters everywhere. - That the circuit::handshake module already does most of what we want.
* | tor-rtcompat: CompoundRuntime: Add a CoarseTimeProvider, and implIan Jackson2024-03-251-0/+1
|/ | | | | | In all the uses in-crate, this is just a RealCoarseTimeProvider. Now all the compound runtimes impl CoarseTimeProvider.
* Propagate RelayCellFormat selection up to where format decisions will be madeJim Newsome2024-03-201-2/+4
|
* hsclient: Clarify "hs_hops" to avoid confusion.Nick Mathewson2024-03-141-6/+11
| | | | | | | With the new structure here, it's less likely that somebody will think this is the length of a circuit that we are building. See #1332 for an instance of what we're trying to prevent.
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* tor-circmgr: Add UniqId to CircTimeout.Gabriela Moldovan2024-02-271-1/+1
| | | | Part of #1297
* tor-netdir: Make hs_dirs_{upload, download} take separate args instead of tuple.Gabriela Moldovan2024-01-241-1/+2
| | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1904#note_2987777
* hsclient: Remove comment about tearing down circuit.Nick Mathewson2023-12-111-2/+0
| | | | This is now in the spec, with torspec!236.
* hsclient: Clean up some TODOs about parallelism.Nick Mathewson2023-12-051-7/+8
| | | | | | | | * Be a little more specific about what is being parallelized. * Remove TODOs about specs, in favor of torspec#244. * Note some other issues surrounding some of the cases. (See discussions of points 3-6 at #913)
* Fix typo in argumentshalcyon2023-10-201-1/+1
|
* hsclient: add a missing ) to a message.Nick Mathewson2023-10-171-1/+1
|
* dirclient: Seal the Requestable trait and hide most of its members.Nick Mathewson2023-10-171-1/+1
| | | | | | | | Since none of these methods were invoked from outside `tor-dirclient` (except for debugging), and since we have had a fair amount of churn on what we actually want them to be, it seems like a good idea to use this trick to hide them. This will let us make other changes to the actual behavior of Requestable in the future.
* tor-hsclient, arti-client, tor-keymgr, tor-netdoc: Use a keypair instead of ↵Gabriela Moldovan2023-09-251-6/+2
| | | | StaticSecret (fmt).
* tor-hsclient, arti-client, tor-keymgr, tor-netdoc: Use a keypair instead of ↵Gabriela Moldovan2023-09-251-7/+7
| | | | | | | | | | | | | StaticSecret. Previously, when retrieving `KS_hsc_desc_enc` keys (or any other x25519 keys) from the keystore, the keymgr would discard the public part of the key (SSH private keys contain the public part of the key too). Instead of discarding the public key and returning just the `StaticSecret`, the keymgr now returns a `StaticKeypair`. This makes the x25519 `EncodableKey`/`ToEncodableKey` implementation consistent with the ed25519 one (which retrieves key pairs rather than "unescorted" secrets).
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-231-0/+1
|
* tor-netdir: Use an owned HsBlindId instead of a reference.Gabriela Moldovan2023-08-221-1/+1
| | | | `HsBlindId` is `Copy`.
* tor-hsclient: Use hs_dirs_download instead of the deprecated hs_dirs.Gabriela Moldovan2023-08-221-6/+5
|
* tor-dirclient: Rename download() to send_request().Gabriela Moldovan2023-08-161-1/+1
| | | | | | `download()` is actually a general-purpose function for sending HTTP requests on a stream. We will soon repurpose it for `POST`-ing descriptors, so let's rename it to `send_request`.
* tor-proto: Add ClientCirc::start_conversation().Gabriela Moldovan2023-08-041-3/+4
| | | | | | | | | | | This will enable hidden services to send `RENDEZVOUS1` messages to the `N`th hop of the circuit rather than the `N + 1`th virtual one (which can only used after the client and service have completed the introduction handshake). This also deprecates `start_conversation_last_hop`. Closes #959
* Run cargo +nightly fmt to format many let ... else ...Ian Jackson2023-07-241-2/+6
| | | | | | | | | | | rustfmt has grown opinions about how let ... else ... ought to be formatted. They don't always agree with our previous manual decisions. I think our policy is to always insist on rustfmt. When that version of rustfmt hits stable, our CI will start to fail for everyone. (Right now this discrepancy just causes trouble for contributors who are using nightly by default.)
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:29:21 +0000