| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 => ...
}
```
|
| |
|
|
|
|
|
| |
This warning suggests using `[a,b]` as a Pattern
when it sees a search for `|ch| ch == a || ch == b`.
(All of our supported rust versions allow this kind of Pattern.)
|
| |\
| |
| |
| |
| |
| |
| | |
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 commit is automatically generated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| | |
|
| | |
|
| |
|
|
|
| |
FTR I don't think agree with clippy on this question, but then I often
don't.
|
| |
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
| |
This is what the C Tor HsDirs want.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1039
|
