This will enable us to test the parts of `ArtiNativeKeystore::insert`
that _are_ implemented (such as the part where it creates the missing
directories).
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?":
36606a66dd/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 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).
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.
Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
Gabriela Moldovan
Dimitris Apostolou
Nick Mathewson
Ian Jackson
Ian Jackson