| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
| |
valid_until.
As per our discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2577#note_3099356
|
| | |
|
| |
|
|
|
|
|
| |
This will enable us to store more than one `K_relaysign_ed` in the
keystore.
Closes #1692
|
| |
|
|
|
|
|
| |
We'll eventually need this specifier (for example, if the
`KS_relayid_ed` private key stored offline, the public part of the
keypair will be stored in the online keystore, and will be retrievable
using the new `RelayIdentityPublicKeySpecifier` specifier).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
According to its docs, `RelayIdentityKeySpecifier` was meant to be the
key specifier for the relay identity keypair, so its role prefix should
be `KS_`.
This also renames `RelayIdentityKeySpecifier` to
`RelayIdentityKeypairSpecifier` for clarity (we're about to add another
specifier here, for the public relay identity key).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `RelaySigningKeySpecifier` is currently defined as:
```rust
#[non_exhaustive]
#[derive(Deftly, PartialEq, Debug, Constructor)]
#[derive_deftly(KeySpecifier)]
#[deftly(prefix = "relay")]
#[deftly(role = "KP_relaysign_ed")]
#[deftly(summary = "Relay medium-term signing keypair")]
/// The key sepcifier of the relay medium-term signing key (RelaySigningKeypair)
pub struct RelaySigningKeySpecifier;
```
This means there can only be a single `relaysign_ed` key with an
`ArtiPath` of the form `relay/KP_relaysign_ed`. This is a problem,
because relays storing their identity key offline will want to generate
a number of `relaysign_ed` keys ahead of time, so we need the keystores
to be able to contain multiple such keys. We will need their `ArtiPath`
to encode a variable component (for example, a timestamp).
We also need to teach `KeyMgr` to retrieve such keys (`KeyMgr::get`
should return the first key that has a valid and timely certificate).
This will involve extending the `KeySpecifier` trait with a function for
obtaining the `KeySpecifier` of the certificate of the key, if there is
one.
For now, let's comment it out and rethink its `ArtiPath` as part of
#1692.
|
| |
|
|
|
|
|
|
|
| |
This re-exports the types/traits needed by the `define_ed25519_keypair`
macro so that the macro caller doesn't need to import a bunch of extra
packages in its Cargo.toml that it doesn't use, and so that the caller
doesn't need a `use prelude::*` before invoking the macro. This makes
the macro nicer to use for the caller, and should prevent the macro from
causing "cannot find ... in this scope" errors.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
|
|
This adds a new crate called tor-relay-crypto which is responsible for
declaring the relay keys and certificate that will be used by a relay
and stored in a KeyMgr.
This is in its own crate and considered pretty low level so other crates
can use it to access the relay keys, like tor-proto, for cryptographic
actions like channel authentication or descriptor signing.
The lower level cryptographic keys are wrapped in a higher level object
in this crate, using tor-key-forge crate, so we can have proper semantic
and strong type check on those keys so they are not misused or confused
with other keys.
At this point, the key declaration might change once the KeyMgr supports
attaching a certificate to a key. We are likely going to see more code
related to certificate creation in this crate in the future.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
