These have been subsumed by other errorkinds, mostly
OnionServiceProtocolViolation and TorProtocolViolation.
In particular please review the change in tor-hsclient closely;
I am not sure about the new errorkinds for the error there.
For higher-level HsDesc-related functions, this type indicates where
exactly an error occurred. It lets us distinguish decryption errors
from parsing errors, and attribute responsibility to the hsdir, the
onion service, or the user's lack of encryption.
This lets us remove some just-introduced complexity in
tor-hsclient.
This takes an approach discussed in #736: Instead of trying to
distinguish INTRO/REND failures perfectly, we instead map our
existing ErrorKinds as best we can, in respect to the fact that
this distinction is not super important in practice.
Closes#736
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).
Nick Mathewson
gabi-250
Alexander Færøy
Ian Jackson
Ian Jackson
Saksham Mittal