| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
I find these names confusing. To my mind "check" implies a function
returning `Result<(), _>`.
Some other APIs use `unwrap` here but I think `if` is good.
|
| |
|
|
|
|
|
|
|
|
| |
This just returns a tuple.
We're going to introduce a new method that returns a `TimeRagne` and
will want to be called `bounds`.
That method will want to be in the `TimeBound` trait, but for now we
add it here. Various call sites will be added in forthcoming commits.
|
| | |
|
| | |
|
| |
|
|
|
| |
This saves us from having to check whether it is 0, and better
represents what the type is allowed to be.
|
| |
|
|
|
|
|
|
| |
The "flow-control" item is documented in proposal 324 section 9.1;
there's a ticket (torspec#418) to document it.
The "proto" item is documented at
https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#item:proto
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
| |
Part of #2492 phase 2.
|
| |
|
|
| |
This silences a new warning on nightly.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
| |
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
|
| |
|
|
|
|
|
| |
I'm about to make our parsers reject some strings at construction
time, so it makes sense to have these functions become fallible.
This is a breaking change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full
features with a single hs-pow-full feature.
It's possible that in the future we will want to split different schemes
into different features, but we can do that when it comes up.
For now, having this as a single flag makes it clearer what's going on,
since the previous thing was not actually expressive enough to capture
some things we care about (like "at least one pow scheme is enabled"
that works in a future-compatible way).
This change is not semver breaking since it's a experimental feature.
Related: #1751
|
| |
|
|
| |
Fixes: #1691
|
| |
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
|
| |
This can now notice pow_params lines which are invalid because they have
no parameters.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
This implements support for extensible proof-of-work parameters. Right
now only a single type is defined, but in theory we can see up to one
line per type on an onion service.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| | |
|
| |
|
|
|
|
| |
Closes #1221.
See torspec!240 for a corresponding spec change.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
None of the existing NetdocErrorKinds seemed right.
|
| |
|
|
| |
(We explicitly do not care if Arti can be distinguished from C tor.)
|
| |
|
|
|
| |
This resolves some TODO HS items now that we are confident we want
to have these actual examples in our tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
`ParseErrorSource` was originally meant to represent a parsing error,
this enum has since gained some variants that aren't really parsing
related (`Signature`, `CertSignature`, `UntimelyDescriptor`).
Since this error type is now used for general-purpose netdoc errors,
let's rename `ParseError{Kind, Source}` to `NetdocError{Kind, Source}`.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes
cargo +stable test --locked --offline F -p tor-netdoc
cargo +stable clippy -p tor-netdoc F --all-targets
for values of F including
--all-features
--features=hs-client
--features=hs-common
--features=hs-service
(nothing)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the `NetdocBuilder` trait described in
`netdoc-builder.md` and a new `tor-netdoc::doc::hsdesc::build` module,
which exports the `HsDescBuilder`. Hidden services will use
`HsDescBuilder` to build and encode hidden service descriptors.
There are several TODOs in the code that I'm planning to address
separately.
Partially addresses #745.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes our implementation behave the same as the C tor
implementation, by validating all of the expiration and signatures
on the certificates in the inner document.
(It is still not semantically necessary to check these certs: the
document in which they appear is already signed by the key with
which they are allegedly signed.)
Closes #744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It said to check whether C enforces an absence of extraneous bytes
at the end of the link specifiers. It does, in
`hs_desc.c:decode_link_specifiers()`, where it says:
```
if (link_specifier_list_parse(&specs, decoded,
(size_t) decoded_len) < decoded_len) {
goto err;
}
```
The comparison with "decoded_len" checks whether all the bytes were
decoded.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We want to fuzz these parsers, but there's no currently way to get
at the parsers for inner documents without going through a lot of
encryption. (Coverage-guided fuzzers are powerful, but they
can't find SHA3 preimages.)
|
| |
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1016#note_2877759
"_prefixed" becomes "_with_header". That mirrors the returned struct
which is nice.
|
| | |
|
| | |
|
| | |
|
