mirrors/arti.git/crates/tor-netdoc/src, branch arti-v1.3.0

Disable a lot of dead code warnings

2024-10-17T10:25:24Z

Now cargo check --workspace --no-default-features --all-targets cargo build -p arti --no-default-features --features=memquota,tokio,native-tls are both clean.

Add a little test coverage for pow-params parsing.

2024-10-09T16:06:01Z

Cover some of the novel edge cases we're introducing around object parameters and repetition. This still feels awfully ad-hoc, but it's better than nothing. Co-authored-by: Micah Elizabeth Scott

hs-pow inner desc: broaden pow-params rule, disallow object for v1.

2024-10-09T16:06:01Z

We should not be restricting pow-params to occur only once at the rule level, and we shouldn't be disallowing object parameters at that level either. Instead, the v1 scheme itself needs to check for and disallow objects. Future schemes may allow object parameters. Test cases for this will be added in a subsequent commit. Co-authored-by: Micah Elizabeth Scott

Fix incorrect doc comment.

2024-10-09T16:06:01Z

Looks like a copy/paste error. Co-authored-by: Micah Elizabeth Scott

hs-pow: inner doc test using canned data from C tor.

2024-10-09T16:06:01Z

This proliferates the canned hsdesc inner doc testing strategy, adding another file with data encoded with onion-pow-example running on C tor. Tests that it parses successfully, and asserts that the pow params line contents are correct. This is a positive test only. This strategy seems problematic, but it's better than nothing. Co-authored-by: Micah Elizabeth Scott

hs-pow: Explain what the v1 scheme refers to, in PowParams.

2024-10-09T16:05:21Z

Adds another breadcrumb as requested so new folks happening upon this in the docs can get oriented. Co-authored-by: Micah Elizabeth Scott

hs-pow: Change rule to require pow_params type parameter.

2024-10-09T16:05:21Z

This can now notice pow_params lines which are invalid because they have no parameters. Co-authored-by: Micah Elizabeth Scott

hs-pow: Use TimerangeBound for puzzle parameters.

2024-10-09T16:05:21Z

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