| 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
|
| |
|
|
|
|
|
|
|
| |
This enables us to get rid of the tor-key-forge -> tor-hscrypto
dependency, partially addressing the TODO from `tor_key_forge::traits`.
This commit is mostly code motion. Best reviewed with `--color-moved`.
See also #1778
|
| |
|
|
|
|
|
| |
We can't possibly know the `ErrorKind` of such an error, unless we know
where the unsupported key came from. Since we can't know this, we should
let a higher level crate (like `tor-keymgr`) decide the `ErrorKind`
instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will enable us to store `tor_cert::EncodedEd25519Cert`s in the
keystore.
|
| | |
|
| | |
|
| |
|
|
| |
This will be used by the `Keystore` implementations.
|
| |
|
|
|
| |
This function now returns a `KeystoreItemType`, enabling us to represent
certs as `EncodableItem`s.
|
| |
|
|
|
| |
This enables us to auto-generate tests for all the supported key/cert
file extensions.
|
| |
|
|
|
| |
Items that have an unrecognized file extension now get mapped to
`KeystoreItemType::Unknown`.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is the first step in replacing `EncodableKey` with the new
`EncodableItem` trait (see doc/dev/keymgr-certificates.md).
(this refactoring is split over multiple commits to make reviewing
easier)
|
| |
|
|
|
|
|
| |
The `EncodableKey` trait will soon be extended to support encoding
certificates too (in addition to keys), so we need a type to represent
an object that is either a key or a certificate (in other words, an
encodable *item*).
|
| | |
|
| | |
|
| |
|
|
|
| |
Soon the keystore will be able to store certs too, so we need something
other than `KeyType` to represent the "type" of a keystore entry.
|
| |
|
|
| |
These are new in Rust 1.83.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
`KeypairData` is already in scope, so there's no need to fully-qualify
it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Part of #1476
|
| |
|
|
|
|
| |
Closes #1619
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the signature::Signer and Ed25519PublicKey trait so the
ed25519 keypair wrapper can be easily used for certificate creation.
This also adds a to_ed25519_id() so we can get a Ed25519Identity which
is an object used around.
Finally, add a prelude module as the list of imports started to grow a
bit out of control.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This comment adds a second associated type `KeyPair` to ToEncodableKey. For a
`ToEncodableKey` which represents a (secret) KeyPair, this type is Self. For
a `ToEncodableKey` which represents a public key, this is the `ToEncodableKey`
whose `Key` is the pair of which this is the public part.
This is essentially a "type level pointer" from the ToEncodableKey for a
public key to the ToEncodableKey for its secret key.
|
|
|
Signed-off-by: David Goulet <[email protected]>
|
