| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Previously, arti's primary keystore was referred to as its "default"
keystore. However, "default" is inaccurate here: there is no way to
meaningfully override this "default" (the "default" store acts as the
main keystore). Throughout the codebase, we query all keystores for keys
(including the secondary ones), but only ever write to the
default/primary keystore. This is OK for now, because it enables us to
have one mutable keystore, and multiple secondary, read-only stores.
|
| | |
|
| |
|
|
| |
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2393#note_3073480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
keypair
Now that:
- KeySpecifier::get_keypair_specifier() can be used to convert the
KeySpecifier for a public key into the KeySpecifier for its secret key
- ToEncodableKey<Key=PublicKey> has a "type level pointer" to
ToEncodableKey<Key=KeyPair>
We can use these two features together to automatically satisfy any request to
get a public key using the corresponding secret key (if available).
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This commit adds a new method `get_keypair_specifier()` to `KeySpecifier`.
This method is used to indicate when one KeySpecifier (e.g. `KP_hs_id`) is the
public part of another keypair (e.g. `KS_hs_id`). It will return the
containing keypair in this case, and `None` otherwise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
FooKeypairSpecifier` instances
This adds the following trivial `From` instances:
- tor_hsservice: impl From<&HsIdPublicKeySpecifier> for HsIdKeypairSpecifier
- tor_hsservice: impl From<&BlindIdPublicKeySpecifier> for BlindIdKeypairSpecifier
- tor_hscrypto::pk: impl From<HsBlindIdKeypair> for HsBlindIdKey
- tor_llcrypto::pk::ed25519: impl From<ExpandedKeypair> for PublicKey
- tor_keymgr::mgr: impl From<TestKey> for TestPublicKey
- tor::hscrypto::pk: impl From<HsIdKeypair> for HsIdKey
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Everything copied in the previous commits to tor-keys is now removed and
tor-keys crate is used accross the code.
Minor changes to tor-keys to accomodate this change.
Part of #1137
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The derive ed25519 keypair macro now implements the keymgr trait so the
key wrapper can now be used with a keystore without needing to specify
it in the tor-keymgr crate.
For this to work, a slight change to the KeygenRng trait was needed as
in to expect the CryptoRngCore trait which is what ed25519-dalek
requires.
And also, the removal of the Sealed trait since now it is accepted to
implement these traits outside tor-keymgr.
Fixes #1137
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the keymgr tests to be slightly more robust.
These tests attach some metadata to each key, such as the "nickname" of
the key (which only exists for testing purposes), whether the key was
auto-generated, and the keystore ID of the keystore from which the key
was retrieved.
Previously, the metadata was encoded in the key "material" itself (the
test "keys" were actually just `String`s with a hacky `EncodableKey`
implementation that abused the "encrypted" variant of `KeypairData`).
This was only possible because we had access to the key internals
(through `SshKeyData::Public`/`SshKeyData::Private`), but since the
internals are inaccessible now, the tests need to be updated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in the docs, this trait should not be implementable outside
of the `tor-keymgr` crate. The `SshKeyData::into_erased` and
`UnparsedOpensshKey::parse_ssh_format_erased` impls assume the types
implementing `EncodableKey` form a statically known closed set.
If we later decide to make the supported key types an open set, we
should make this trait implementable outside of `tor-keymgr` too.
External types wanting to create custom "key types" for use in the
keymgr should use the non-sealed `ToEncodableKey` trait, which specifies
the `EncodableKey` type to use.
This trait is mainly used to create `SshKeyData` IMO, we should make
`SshKeyData` opaque, since it's not meant to be constructed through
other means (`SshKeyData` is currently a public enum, so its variants
and the `ssh_key` types they wrap are public). A future commit will make
it opaque.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I am not so sure it makes sense to unify these functions, so let's
remove the TODO.
|
| | |
|
| | |
|
| |
|
|
| |
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| | |
|
| |
|
|
|
|
|
| |
NB: `KeyMgr::remove_with_type` will need to be renamed to
`KeyMgr::remove_entry`.
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| |
|
|
|
|
|
|
|
|
| |
This type will soon replace `(KeyPath, KeyType)` in
`KeyMgr::list_matching`.
The KeystoreEntry documentation mentions a couple of functions that
don't exist right now (they will be added in a subsequent commit).
Part of #1271
|
| | |
|
| |
|
|
| |
Part of #1115
|
| |
|
|
| |
Part of #1115
|
| |
|
|
|
|
| |
Bailing on the first inaccessible keystore is correct.
Part of #1115
|
| | |
|
| |
|
|
|
|
| |
This trait extracts a `KeyPathInfo`, not a `KeyInfo`.
Part of #1115
|
| |
|
|
| |
(These were broken by recent MRs so don't need a CHANGELOG update in !1950.)
|
| | |
|
| | |
|
| |
|
|
|
| |
We are about to remove `KeyMgr::get_or_generate_with_derived`,
so this rewrites `KeyMgr::get_or_generate` without using it.
|
| | |
|
| |
|
|
|
|
|
| |
`KeyMgr::generate` is now quite similar to `KeyMgr::get_or_generate`, so
we will soon remove the latter.
Part of #1074
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
arti#1151 item 1.
|
| |
|
|
|
| |
Fixes
cargo doc --locked --workspace --all-features --document-private-items
|
| | |
|
| |
|
|
|
| |
Sometimes we need to remove a key without knowing its concrete (Rust)
type (only its `KeySpecifier` and `KeyType`).
|
| | |
|
| | |
|
