| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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`.
|
| |
|
