This previously just re-exported `ssh_key::Algorithm`.
However, we will need to support x25519 keys (which aren't supported by
the `ssh_key` crate), so we define our own enum for the key algorithm.
In addition to the `Algorithm` variants from `ssh_key`, our enum also
has an `X25519` variant.
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).
The dummy key manager impl from `arti-client` will be moved to
`tor-keymgr` soon. This commit adds a `keymgr` feature flag to
`tor-keymgr` which will eventually be used to choose between the real
key manager API and the dummy one.
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
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 need to special-case `NotFound` errors because
`ssh_key::PrivateKey::from_openssh` doesn't read from disk (so it
shouldn't be returning `NotFound` errors in the first place).
Previously, this condition made sense because we were using
`ssh_key::PrivateKey::read_openssh_file` instead of
`ssh_key::PrivateKey::from_openssh`, which _does_ read from disk. This
condition should have been removed in !1263 (the refactoring where we
switched to `from_openssh`).
(Also, after #901 is implemented, we probably won't have an
`Error::NotFound` error anymore).
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).
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).
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
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`.
This adds a proof-of-concept `SshKeyType::read_ssh_format_erased`
implementation for `KeyType`. The implementation decodes an OpenSSH key
and converts it to one of the key types used internally by Arti. The
value returned is type-erased, and will be downscast later down the line
by the `KeyMgr` (note: `KeyMgr` doesn't exist yet).
The `SshKeyType::write_ssh_format` will be implemented once these APIs
are a bit more stable.
Gabriela Moldovan
Alexander Færøy
Ian Jackson
Ian Jackson