| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
Not having the flavour in the type name is a shame, but we probably
don't want to resort to generating the docs with macros.
Part of making these two files largely identical.
|
| |
|
|
| |
Part of making these two files largely identical.
|
| |
|
|
|
| |
Move the implementation to the trait method which then becomes
completely identical in both files.
|
| |
|
|
| |
Part of making ns.rs and md.rs largely identical.
|
| |
|
|
| |
Part of making these two files largely identical.
|
| |
|
|
|
|
|
| |
In the species-specific files ns.rs and md.rs, use the unqualified
name; re-export it with the new macro.
We are working towards making these two files largely identical.
|
| |
|
|
|
| |
This will let us deduplicate a fair amount of code, and also will let
us support votes as well as ns and md consensuses.
|
| | |
|
| |
|
|
| |
Cut-and-paste error, I think.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
|
| | |
|
| |
|
|
|
| |
It would be better to take a more sophisticated approach;
see #2048.
|
| | |
|
| |
|
|
|
| |
In particular, these are errors that provide an opportunity to
inflate the size of an hsdesc download.
|
| |
|
|
|
| |
These errors are suspicious as hsdir inflation attacks, in the
context of prop360.
|
| |
|
|
| |
Part of proposal 360.
|
| |
|
|
|
|
| |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
|
| |
> The actual impact of this patch is to prevent usage of MiddleOnly
> relays as Introduction Points. The Rendezvous Point logic isn't
> hooked up yet - nick
|
| |
|
|
|
| |
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We'll want this so that we can expose them before we expose the rest
of the consensus (which we need to do for spec conformance).
|
| |
|
|
| |
Also, add a new ErrorKind for this sort of error.
|
| |
|
|
| |
- The Rng::gen() functions have been renamed to Rng::random().
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
| |
This is partly for consistency, and partly to facilitate
a global search-and-replace.
|
| |\
| |
| |
| |
| | |
Wrap x25519-dalek and ed25519-dalek types.
See merge request tpo/core/arti!2868
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
|
| |/
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I'm not particularly happy with the code that does the actual writing
out of the pow-params line, in particular the error handling there seems
very verbose. However, I don't know of a better way to structure it
given that APIs I'm working with.
|
| |
|
|
| |
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]>
|
| |
|
|
|
|
|
| |
Adds another breadcrumb as requested so new folks happening upon this in
the docs can get oriented.
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]>
|
| |
|
|
| |
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]>
|