| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
This function no longer returns `KeypairData` (it now returns
`SshKeyData`).
|
| |
|
|
|
|
|
|
|
| |
Previously, `EncodableKey::to_keypair_data` could only be used for
encoding private keys (its return type was `KeypairData`). Now
`EncodableKey::to_keypair_data` can return public key data (`KeyData`)
too.
Note: `to_keypair_data()` will be renamed in a future commit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The `KeypairData` type from [ssh-key] at some point leaked into the
keymgr API (via the `EncodableKey` trait). Instead of re-exporting just
`KeypairData`, let's re-export the entire `ssh_key` crate
(`EncodableKey` implementors would need additional types from `ssh_key`
to construct a `KeypairData` object anyway).
[ssh-key]: https://crates.io/crates/ssh-key
|
| |
|
|
|
|
|
|
|
|
|
| |
The `EncodableKey::to_bytes` function didn't make much sense, because
not all keys have a canonical byte representation.
This commit replaces `EncodableKey::to_bytes` with
`EncodableKey::as_ssh_keypair_data`. In the future, `EncodableKey` will
grow functions for encoding keys in other storage formats too.
Closes #965
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| |
|
|
|
|
| |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| |
|
|
| |
keys from." (fmt)
|
| |
|
|
|
|
|
|
|
| |
keys from."
This reverts commit 38a6c74c7894dc96b16c9039cacc2a4023977b05.
This also updates some tests to make them compile with the reverted
version of the code.
|
| |
|
|
|
| |
As with `KeyMgr::insert`, only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| |
|
|
|
|
|
|
|
|
| |
The caller uses `KeystoreSelector` to specify which keystore to insert
the new key into (only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported for `insert`).
The ability to insert keys in a particular keystore will come in handy
when we implement the key management CLI (the CLI will have an option
for specifying the keystore to access/modify).
|
| |
|
|
|
|
| |
This error will be returned by `KeyMgr` if the caller tries to access a
keystore that does not exist, or if the requested `KeystoreSelector`
cannot be applied.
|
| |
|
|
|
| |
This will be used by `KeyMgr::insert` after we add an additional
argument to `insert` for specifying the keystore it should be using.
|
| | |
|
| | |
|
| |
|
|
| |
This makes the code slightly less verbose.
|
| |
|
|
|
| |
We've been capitalizing the "s" in "KeyStore" inconsistently. This
`s/KeyStore/Keystore/g` across the codebase.
|
| |
|
|
|
| |
These TODOs can be deferred for now: we're not declaring the keymgr APIs
stable until we add support for hidden services.
|
| |
|
|
| |
Part of #901
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
We don't really need "key bundles" for the client keys.
|
| |
|
|
|
|
|
| |
This simplifies usage quite a bit and will enable us to implement a
dummy `KeyMgr` that doesn't depend on the error types from tor-keymgr
(which will replace the "real" `KeyMgr` if the keymgr feature is
disabled).
|
| |
|
|
|
|
|
| |
This means `KeyMgr` users don't need to specify the underlying key type
(e.g. `ed25519::Keypair`) when retrieving keys. Instead, they can just
specify the type required (as long as it implements `ToEncodableKey`),
e.g. `HsClientIntroAuthKeypair`.
|
| |
|