| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`).
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Eventually these will need to be auto-generated, but that is not
possible right now.
Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1760#note_2969841
|
| |
|
|
| |
We don't use this now that we have a `KeyMgrBuilder`.
|
| | |
|
| |
|
|
|
|
|
| |
`KeyMgr` is soon going to have more fields, so now is a good time to
derive `Builder` for it.
Closes #1114
|
| | |
|
| | |
|
| |
|
|
| |
The module is private so it won't show up in the public docs.
|
| | |
|
| |
|
|
|
|
| |
We don't really need it.
Closes #1066
|
| | |
|
