mirrors/arti.git/crates/tor-keymgr/src/keystore, branch ios-sqlite-hacks

tor-keymgr: Remove redundant _private suffix from key extension.

2023-09-12T15:56:15Z

The privateness of the keys is encoded in their name.

Run maint/add_warning to add lint block everywhere

2023-08-23T09:34:00Z

tor-error: Remove KeystoreFsPermissions variant.

2023-08-08T15:46:20Z

According to the `ErrorKind` lumping guidelines, `KeystoreFsPermissions` should be lumped with `FsPermissions`: they represent the same type of error, and their "location" is the same ("Host"). Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1315#note_2916455

keymgr: Implement SshEncodableKey for ed25519::Keypair.

2023-08-02T13:21:06Z

keymgr: Remove KeyType::to_ssh_format.

2023-08-02T13:21:02Z

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`.

keymgr: Test whether insert() creates the missing directories.

2023-07-24T12:17:16Z

keymgr: Create the parent directories as needed

2023-07-24T12:17:08Z

keymgr: Add a Keystore::contains accessor.

2023-07-24T12:17:05Z

keymgr: Use KeystoreId instead of a static string.

2023-07-21T11:36:29Z

keymgr: Remove unimplemented/unnecessary has_key_bundle function.

2023-07-20T18:24:44Z

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 --keystore hsm ...) ``` For more details, see the discussion on #903. Closes #903