| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
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]>
|
| | |
|
| |
|
|
| |
Part of #1476
|
| |
|
|
|
|
| |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nightly rust doesn't like it when you have a `match` arm that can
never be reached because of an uninhabited type. As such,
we can't say stuff like:
```
let x: Option<Void> = ...;
match x {
Some(_) => unreachable!(),
None => ...
}
```
|
| |\
| |
| |
| |
| |
| |
| | |
tor-netdoc: Dangerously expose annotation fields
Closes #1469
See merge request tpo/core/arti!2213
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit exposes the fields of `routerdesc::AnnotatedRouterDesc` and
`routerdesc::RouterAnnotation` with the enabled feature
`dangerous-expose-struct-fields`.
On one side, it achieves a greater consistency among the other
structures found within this module; On the other side it makes the
already public API (assuming the feature above is enabled) useable.
Fixes #1469
|
| | | |
|
| |/
|
|
|
| |
This is the client-side part of phase 1 for proposal 350,
which will eventually remove TAP completely from the Tor network.
|
| |
|
|
|
| |
The use of cfg(fuzzing) here is reasonable and localized, but we
need to permit it to avoid a warning from #1395.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the combination of a number of separate commits, many of which
were generated by seddery, and then rebased and squashed.
Cargo.toml
perl -i~ -pe 's{^derive-adhoc}{derive-deftly = "0.10"}' crates/*/Cargo.toml
(not regenerated during rebase)
update Cargo.lock
`cargo fetch` without --locked
(regenerated during rebase)
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{^use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bdefine_derive_adhoc\b}{define_derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bAdhoc\b}{Deftly}g if m{derive}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[derive_adhoc\b}{#[derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc\b}{derive_deftly_adhoc} if m{use.*deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc!}{derive_deftly_adhoc!}'
(not regenerated during rebase)
Manually add `#[derive_deftly_adhoc]` where needed.
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[adhoc\b}{#[deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc_template}{derive_deftly_template}'
(not regenerated during rebase)
Manually fix up an import
Manually update some builder attrs
Manually fix up tor_rtmock::time_core
This was missed in my seddery, due to me rebasing the branch and not
redoing the seddery.
|
| | |
|
| |
|
|
| |
(For testing.)
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
hsdesc: Document why enc_key_cert signbit is always zero.
Closes #1221
See merge request tpo/core/arti!1888
|
| | |
| |
| |
| |
| |
| | |
Closes #1221.
See torspec!240 for a corresponding spec change.
|
| |/
|
|
|
| |
(We don't need Fast right now, but we will certainly need it down
the line.)
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1019
|
| |
|
|
|
| |
With this change, we no longer expose the ExpandedSecretKey
unescorted, which makes it harder to misuse the API.
|
| |
|
|
| |
(These types were all already re-exported from pk::ed25519.)
|
| |
|
|
|
|
|
|
|
|
| |
This code was needed with the old version of dalek-cryptography,
which wasn't compatible with up-to-date versions of the `rand`
crate(s). But now that we've upgraded, we can drop this.
(We could have left it around and deprecated it, but we are already
making a breaking change to tor-llcrypto by upgrading
dalek-cryptography.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Representing the supported HTYPEs as `HandshakeType`s instead of `u32`s
makes it more difficult to pass in wrong/invalid values to
`HsDescBuilder::create2_formats`.
This also fixes a descriptor publisher bug spotted by @jnewsome, where
the advertised CREATE2 HTYPEs included HTYPE `1`, which is actually
supposed to be a reserved value. The publisher now only advertises the
`NTOR` HTYPE (just like C Tor).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
`Bug` wasn't necessarily the right error type here. Plus, with the new
error type adding new errors (i.e. `CertEncodeError` variants), is not a
breaking change.
|
| |
|
|
| |
blinded_id.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
argument.
This will enable us to (eventually) the load the descriptor signing key
cert from the keystore (as opposed to always recomputing it when
building the `HsDesc`).
Part of #1048
|
