mirrors/arti.git/crates/tor-hsclient/src/connect.rs, branch arti-v1.3.0

Use HsPowClient.

2024-10-09T16:05:21Z

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

hs-pow: Refactor to prefer stub types rather than cfg sprawl.

2024-10-09T16:05:15Z

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

tor-hspow: Big refactor, dissolve this crate

2024-10-09T16:04:35Z

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

First pass at implementing onion proof-of-work client

2024-10-09T16:04:35Z

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

tor-cell: Support encoding proofs-of-work in intro_payload

2024-10-09T16:04:35Z

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

Remove hard tabs in the one file that has them.

2024-10-02T14:37:15Z

Fix a couple of lifetime warnings from nightly.

2024-10-01T14:14:45Z

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 Runtimes

2024-09-24T13:10:11Z

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'

2024-03-26T16:16:35Z

Refactor the logic for constructing crypt layers. See merge request tpo/core/arti!2048

Refactor the logic for constructing crypt layers.

2024-03-26T15:43:43Z

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.