| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
| |
```text
warning: duplicated attribute
--> crates/tor-hsservice/src/timeout_track.rs:630:14
|
630 | #![allow(clippy::needless_pass_by_value)] // TODO hoist into standard lint block
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will enable us to deserialize byte slices as `EncodedEd25519Certs`.
Needed because this type will be used to representing a parsed + validated
cert retrieved from the keystore.
Technically, we *could* do without this function by defining a separate
newtype wrapper over `Vec<u8>` to represent the validated cert data, but
IMO adding a second encoded ed25519 cert type in another crate might be
confusing later down the line (because the two types will be nearly
identical, and are bound to eventually diverge in terms of API and
implementation).
Part of #1137
|
| |
|
|
| |
Part of #1768
|
| | |
|
| |
|
|
|
|
| |
This adds an experimental API for creating an `EncodedEd25519Cert` from
a byte slice. We will need this in `ArtiNativeKeystore` for
deserializing the on-disk certs to `KeystoreItem`s.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This commit introduces a test for unrecognized `tor_cert::CertExt`
fields.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hidden services use blinded singing keys derived from the identity key
to sign descriptor signing keys.
Before this patch, the hidden descriptor builder represented its blinded
signing keys (`blinded_id`) as plain `ed25519::Keypair`s. This was not
ideal, as there was nothing preventing the caller from accidentally
initializing `blinded_id` with an unblinded keypair.
This introduces a new `HsBlindKeypair` type to represent blinded
keypairs.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning `clippy::bool_to_int_with_if` is meant to shout at you
when you say `if x { 1 } else { 0 }` and instead suggest that you
say `inttype::from(x)`.
I agreed with this for the case in tor-cert, where we are literally
converting a boolean into a flag.
I don't agree with this in tor-netdoc, where we are using a boolean
to decide how many fields to skip in a given document format. So
for this case, I decided to clean up the code a little by renaming
"skip" to "n_skip", and changing the boolean to use an enum instead.
|
| |
|
|
| |
and propagate to other affected crates
|
| | |
|
| | |
|
| |
|
|
| |
This lets us remove a few TODOs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comprises four renames:
```
write_onto -> write_onto_infallible
write_into -> write_into_infallible
write -> write_infallible
writer_and_consume -> write_and_consume_infallible.
```
The rest of this branch will be concerned with replacing these
`_infallible` methods with ones that return a `Result`. This is
part of #513.
|
|
|
This is behind a feature flag, since it isn't needed for pure
clients: only onion services and relays need this.
I've named the object that constructs these certs
`Ed25519CertConstructor` because it doesn't follow the builder
pattern exactly: mainly because you can't get an Ed25519Cert out of
it. _That_ part is necessary because we require that an Ed25519Cert
should only exist if the certificate was found to be well-signed
with the right public key.
Closes #511.
|
