| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| |
|
|
|
|
| |
This will enable the `KeyMgr` to look up `Keystore`s by ID (which is
a requirement for disambiguating the semantics of `insert`, which
currently tries to "guess" which keystore it should be using).
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701
This will make it harder to accidentally return the wrong value from
`Keystore::get` (the returned value is now at least guaranteed to
implement `EncodableKey`).
Closes #937
|
| |
|
|
|
| |
We've been capitalizing the "s" in "KeyStore" inconsistently. This
`s/KeyStore/Keystore/g` across the codebase.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will enable future tests to optionally initialize the test key
store with some test keys.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We don't really need the `AsRef<dyn StdError>` impls if we make
`StdError` a supertrait of `KeystoreError` (and remove the `AsRef<dyn
StdError>` trait bound).
|
| | |
|
| | |
|
| |
|
|
| |
Part of #901
|
| |
|
|
| |
Part of #901
|
| |
|
|
| |
This TODO talks about a change we've decided not to implement.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This also updates `ArtiNativeKeyStore`'s `KeyStore::remove`
implementation to build the absolute path of the file being removed, by
joining `self.keystore_dir` and the relpath returned by
`ArtiNativeKeyStore::key_path()`.
This addresses #908
|
| |\
| |
| |
| |
| | |
keymgr: Remove Error::NotFound, update KeyMgr, KeyStore APIs.
See merge request tpo/core/arti!1280
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes the `NotFound` `tor_keymgr::Error` variant. Since `KeyMgr`
and `KeyStore` users will need to be able to distinguish between "not
found" errors and other I/O errors, this also changes the return types
of the `get()` and `remove()` functions of `KeyStore` and `KeyMgr`,
which now return `Ok(None)` instead of `Error::NotFound`.
This makes the `KeyStore` API consistent with `KeyMgr::get`, which
already has a return type of `Result<Option<K>>` (rather than
`Result<K>`).
This also prepares us for #901, which will make key store errors
opaque. Without this change:
* we'd have to create a `struct NotFoundError;` error type. Its
`HasKind` impl would need to return a new
`ErrorKind::KeyStoreErrorNotFound` `ErrorKind` variant
* callers would have to match the `error_kind()` of the error to
figure out whether the key simply can't be found
(`ErrorKind::KeyStoreErrorNotFound`), or if something went wrong
(any other `ErrorKind`).
Given the above, I think `Result<Option<()>>` makes for a more ergonomic
API.
Part of #901
|
| |/
|
|
|
| |
This TODO describes something we're not planning to implement, so let's
just remove it.
|
| | |
|
| |
|
|
| |
keystore.
|
| |
|
|
|
|
| |
The functions that handle OpenSSH-formatted keys now no longer read or
write from disk. This commit updates their names and doc strings to stop
suggesting they do.
|
| |
|
|
|
|
|
| |
This moves the filesystem calls from the `ssh` module to
`ArtiNativeKeyStore`. While `ArtiNativeKeyStore` shouldn't be concerning
itself with filesystem operations either, that refactoring will be
tackled separately (see arti#899).
|
| |\
| |
| |
| |
| | |
keymgr: Change "TODO hs" to "TODO HSS".
See merge request tpo/core/arti!1264
|
| | |
| |
| |
| | |
We don't really need "key bundles" for the client keys.
|
| | | |
|
| |/ |
|
|
|
This adds implementation stubs for `ArtiNativeKeyStore`, and introduces
the traits needed to make the `KeyStore` APIs work.
|