| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
I am adding `is_enabled()` back because I plan to un-deprecate the
`enabled` setting.
|
| |
|
|
|
|
|
|
|
|
| |
Previously, arti's primary keystore was referred to as its "default"
keystore. However, "default" is inaccurate here: there is no way to
meaningfully override this "default" (the "default" store acts as the
main keystore). Throughout the codebase, we query all keystores for keys
(including the secondary ones), but only ever write to the
default/primary keystore. This is OK for now, because it enables us to
have one mutable keystore, and multiple secondary, read-only stores.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* Bump in Cargo.toml
* Deal with `${Xmeta as ...}` incompatible change, by
always specifying an `as`, and changing `as tokens`.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1202
|
| |
|
|
|
| |
It appears within the public API (it is the error type returned from
`KeySpecifierComponent`), so let's make it public.
|
| |
|
|
|
|
| |
The offending `ArtiPath` should be included in the error.
Part of #1115
|
| |
|
|
|
|
|
|
|
| |
Originally, these functions converted to and from `ArtiPathComponent`.
In !1931, we replaced `ArtiPathComponent` with `Slug` without renaming
the conversion functions. Since we're converting to and from `Slug` now,
I think it makes sense to rename them too.
Part of #1115
|
| |
|
|
| |
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| |
|
|
|
|
|
| |
NB: `KeyMgr::remove_with_type` will need to be renamed to
`KeyMgr::remove_entry`.
Part of #1271
|
| |
|
|
| |
Part of #1271
|
| |
|
|
|
|
|
|
|
|
| |
This type will soon replace `(KeyPath, KeyType)` in
`KeyMgr::list_matching`.
The KeystoreEntry documentation mentions a couple of functions that
don't exist right now (they will be added in a subsequent commit).
Part of #1271
|
| |
|
|
| |
Part of #1115
|
| |
|
|
| |
Part of #1115
|
| |
|
|
|
|
| |
This trait extracts a `KeyPathInfo`, not a `KeyInfo`.
Part of #1115
|
| |
|
|
| |
Part of #1115
|
| | |
|
| |
|
|
|
|
|
| |
This will be returned by `KeyMgr::generate` if the key to be generated
already exists and `overwrite` is `false`.
Part of #1074
|
| |
|
|
|
|
| |
`ArtiPathComponent`s are really just `Slugs`.
Part of #1193, #1092
|
| |
|
|
|
|
| |
This resolves a `TODO HSS` in arti-client.
Part of #1187
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
StaticSecret.
Previously, when retrieving `KS_hsc_desc_enc` keys (or any other x25519
keys) from the keystore, the keymgr would discard the public part of the
key (SSH private keys contain the public part of the key too). Instead
of discarding the public key and returning just the `StaticSecret`, the
keymgr now returns a `StaticKeypair`. This makes the x25519
`EncodableKey`/`ToEncodableKey` implementation consistent with the
ed25519 one (which retrieves key pairs rather than "unescorted"
secrets).
|
| | |
|
| | |
|
| |
|
|
| |
And add a TODO about the error type.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This function isn't actually needed (it's not the responsibility of
`KeyType` to encode keys).
This commit also rewrites `ArtiNativeKeystore::insert` to use the new
`as_ssh_keypair_data` function instead of `to_ssh_format`.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
We'll need this to implement `Keystore::insert`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| |
|
|
|
|
|
|
|
|
| |
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 will enable the `KeyMgr` to look up `Keystore`s by ID (which is
a requirement for disambiguating the semantics of `insert`, which
currently tries to "guess" which keystore it should be using).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
enabled.
Hiding the underlying value of `enabled` enables us to give it a
different `auto` value depending on whether the `keymgr` feature is
enabled or not (it defaults to `true` if `keymgr` is enabled, and
`false` otherwise).
|