| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will enable us to test the parts of `ArtiNativeKeystore::insert`
that _are_ implemented (such as the part where it creates the missing
directories).
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Keymgr api updates minor fixes
See merge request gabi-250/arti!1
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| | |
| |
| |
| |
| |
| | |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| | |
| |
| |
| | |
keys from." (fmt)
|
| |/
|
|
|
|
|
|
|
| |
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`.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 error will be returned by `KeyMgr` if the caller tries to access a
keystore that does not exist, or if the requested `KeystoreSelector`
cannot be applied.
|
| | |
|
| |
|
|
|
| |
This will be used by `KeyMgr::insert` after we add an additional
argument to `insert` for specifying the keystore it should be using.
|
| |
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| |
|
|
| |
This makes the code slightly less verbose.
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the keystore config consisted of a single field in
`StorageConfig`, which encoded 2 bits of information: whether the
keystore is enabled, and its root directory:
```
[storage]
# use this path, fail if compiled out
# keystore = "/path/to/arti/keystore"
#
# use default path, fail if compiled out
# keystore = true
#
# disable
# keystore = false
```
This commit adds `ArtiNativeKeystoreConfig`, which will replace the
multi-purpose `keystore` field. The new config will look like this:
```
#[storage.keystore]
# Whether the keystore is enabled.
#
# If the `keymgr` feature is enabled and this option is:
# * set to false, we will ignore the configured keystore path.
# * set to "auto", the configured keystore, or the default keystore, if the
# keystore path is not specified, will be used
# * set to true, the configured keystore, or the default keystore, if the
# keystore path is not specified, will be used
#
# If the `keymgr` feature is disabled and this option is:
# * set to false, we will ignore the configured keystore path.
# * set to "auto", we will ignore the configured keystore path.
#
# Setting this option to true when the `keymgr` feature is disabled is a
# configuration error.
#enabled = "auto"
# The root directory of the arti keystore
#path = "${ARTI_LOCAL_DATA}/keystore"
```
While `ArtiNativeKeystoreConfig` currently only has 2 fields, `enabled`
and `path`, future versions of the keystore might require additional
config options.
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701
This will make it harder to accidentally return the wrong value from
`Keystore::get` (the returned value is now at least guaranteed to
implement `EncodableKey`).
Closes #937
|
| |
|
|
| |
These are no longer needed.
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |\
| |
| |
| |
| | |
keymgr: Allow periods in ArtiPath and ArtiPathComponent.
See merge request tpo/core/arti!1358
|
| | |
| |
| |
| |
| | |
The docs were lying, we actually support UTF-8 paths (though we might
later decide to restrict the charset further).
|
| | |
| |
| |
| |
| |
| |
| | |
The `ArtiPath` of a client auth key contains the `HsId` of the onion
Since the `HsId` contains a `.onion` component, let's allow `.` for now.
In the future, we may want to update the code (and keystore structure)
to strip away the `.onion` part before building the `ArtiPath`.
|
| |/
|
|
| |
This TODO doesn't need to block the release.
|
| |
|
|
|
| |
We've been capitalizing the "s" in "KeyStore" inconsistently. This
`s/KeyStore/Keystore/g` across the codebase.
|
| | |
|
| |
|
|
|
| |
This also implicitly forbids leading and trailing slashes in an
`ArtiPath`.
|
| |
|
|
| |
This updates the docs with Diziet's suggested doc improvements.
|