| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
| |
We'll soon use this in `ArtiNativeKeystore`'s `Keystore` implementation
for parsing certs read from disk.
|
| | |
|
| | |
|
| |
|
|
|
| |
This will enable us to store `tor_cert::EncodedEd25519Cert`s in the
keystore.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Items that have an unrecognized file extension now get mapped to
`KeystoreItemType::Unknown`.
|
| |
|
|
|
| |
This is part of the work needed to support storing certificates in the
keystore (they won't have a `KeyType`, but rather `CertType`).
|
| |
|
|
|
|
|
|
| |
This is the first step in replacing `EncodableKey` with the new
`EncodableItem` trait (see doc/dev/keymgr-certificates.md).
(this refactoring is split over multiple commits to make reviewing
easier)
|
| |
|
|
|
| |
Otherwise, we get a dead code warning when the `ctor-keystore` feature
is disabled.
|
| | |
|
| | |
|
| |
|
|
|
| |
This moves `assert_found` out of the `keystore::arti::test` so we can
reuse it for testing other keystore implementations too.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The `FilesystemError::Filesystem` variant was actually just for IO
errors.
|
| |
|
|
|
|
|
|
| |
This will be reused by other on-disk key stores (such as the C Tor ones
we're about to add).
I recommend reviewing this commit using
`git diff --color-moved=zebra --ignore-space-change`
|
| |
|
|
| |
This will be used to create relative paths representing C Tor keys.
|
| |
|
|
| |
We're about to add a separate constructor for CTor paths.
|
| |
|
|
| |
We are about to use this for the ctor keystore implementation too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C Tor's client restricted discovery keys don't have the service hsid
encoded in the filename (the hsid of the service each key is associated
with is encoded in contents of the key file). This means that given a
key specifier like `HsClientDescEncKeypairSpecifier` (which is a wrapper
over an HsId), we can't actually compute the relative path of the key in
its `KeySpecifier::ctor_path()` implementation. To do so we would need
to access the keystore to figure out which path contains the requested
HsId, which we can't (and shouldn't!) do from within the `KeySpecifier`
impl.
This suggests the String newtype (representing a relative path) we
previously had is not a good abstraction for `CTorPath`s. Moreover,
`CTorPath` are static (they don't have dynamic components like
`ArtiPath`), so it makes more sense to model `CTorPath` as an enum.
The new `CTorPath::ClientHsDescEncKey(HsId)` variant will be used to
instruct the C Tor client keystore to find the file that contains the
specified `HsId`, while the `Service` variant will be used for hidden
service keys.
|
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Everything copied in the previous commits to tor-keys is now removed and
tor-keys crate is used accross the code.
Minor changes to tor-keys to accomodate this change.
Part of #1137
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
| |
`fs-mistrust` always maps `io::ErrorKind::NotFound` to
`fs_mistrust::Error::NotFound`, so these `io::ErrorKind::NotFound`
branches were unreachable.
|
| |
|
|
|
| |
We now use `CheckedDir::metadata()` to check if the path exists and is
of the correct type.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This makes `rel_path` return a `RelKeyPath` instead of a `PathBuf` to
prevent the accidental misuse of relative key paths (like the one
from #1492).
Closes #1494
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug in `ArtiNativeKeystore`'s `Keystore::contains()`
implementation: previously, it called Path::exists() on the relative
path (built by concatenating the key specifier and the extension), so
unless your current directory happened to be the root of the keystore,
`contains()` would always return `false`.
`KeyMgr::generate` uses `Keystore::contains()` under the hood, so it
was affected by this bug too: if called `overwrite = false`, it would
misbehave and overwrite any existing keys.
Internally, we call `KeyMgr::generate` in a couple of places:
* `tor-hsservice/src/lib.rs`, to generate the `hsid` if it doesn't
already exist. This callsite is not affected by the bug, because
`KeyMgr::generate` is only called if `KeyMgr::get` returns `None`
* `tor-hsservice/src/ipt_mgr.rs`, to generate `KS_hss_ntor` and
`KS_hs_ipt_sid` keys for intro point establishment. This callsite is
also not affected (because it too calls `get()` before attempting to
`generate()`)
The bug affects any downstream users that use `KeyMgr::generate`
with a key manager backed by `ArtiNativeKeystore`.
------
`KeyMgr::get_or_generate` is not affected, even though it calls
`Keymgr::generate` (it performs a separate extra check before calling
`generate()`). (Both suffer from a known TOCTOU race, but that's a
separate matter.) As an aside, I'd like to somehow unify
`KeyMgr::get_or_generate` and `KeyMgr::get` (I've had some attempts in
the past but ended up abandoning them because the result was more
unergonomic than the existing APIs).
Part of #1492
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This new assertion fails, because the implementation of
`ArtiNativeKeystore::contains()` is buggy: it calls Path::exists() on
the relative path built by concatenating the key specifier and the
extension (so unless your current directory happens to be the root of
the keystore, contains() is always going to return false).
Part of #1492
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
`tor-keymgr/testdata` contains a bunch of OpenSSH keys used for testing.
I meant to share the script I generated them with, but somehow never got
around to it.
Note: the OpenSSH keys generated by this script are going to look
slightly different than the ones that are checked into the repo. This is
because some of those original key files were generated ad-hoc (I
manually modified them a while ago, but I forgot exactly how
|
| |
|
|
| |
This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77.
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014
|
| |
|
|
|
|
| |
This helps prevent external users from creating `SshKeyData` out of
unsupported types of `ssh_key::public::KeyData` and
`ssh_key::private::KeypairData`.
|
| |
|
|
| |
KeyData/KeypairData.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The `ssh_algorithm()` function was only meant for use in the
ArtiNativeKeystore, for extracting the `KeyType` given the
`SshAlgorithm` of a key read from disk, so it really shouldn't be
crate-public.
|
| |
|
|
|
|
|
|
|
| |
Some of the types and impls from `key_type/ssh.rs` (such as
`UnparsedOpenSshKey`) have nothing to do with `KeyType`, and are only
used by the `ArtiNativeKeystore`, so I'm moving them to the `arti`
keystore module.
The shared ssh-related stuff now lives in the top-level `ssh.rs`.
|
| | |
|
| |
|
|
|
|
| |
Inserting a key that has the wrong key type no longer fails, because we
now store the `KeyData` as-is, without attempting to parse it as a
specific kind of SSH key.
|