Various road-blocks for implementing a custom KeyStore type

As discussed on IRC earlier today, various downstream consumers of Arti will want to manage their own keys, rather than letting the ArtiNativeKeystore write them to disk.

@gabi-250 suggested to avoid this one could implement a custom struct implementing the Keystore trait. For Gosling, this would be an in-memory only keystore (as key management is left to the library consumer to deal with), whereas for cwtch this could be some translation layer directly to their encrypted sqlite database.

So far I have run into at least these known problems:

• Keystore deals with dyn EncodableKey; this type is not Send + Sync so they must therefore be encoded/converted somehow in order to be stored in a Keystore (which must be Send + Sync). EncodableKey provides as_ssh_key_data() which is Send + Sync so we can therefore convert them to SshKeyData objects for storage. However there seems to be no way to convert SshKeyData back to EncodableKey. KeyType has parse_ssh_format_erased(), but this function is pub(crate) so inaccessible to downstream consumers. Downstream needs one of:
  • Make dyn EncodableKey objects Send + Sync so they can just be stored directly
  • Make the SshKeyData -> EncodableKey machinery public
• The Keystore trait has logically non-const methods (insert, remove) which take immutable &self references. For my memory-backed EphemeralKeystore I will need mutable reference for these methods to modify the backing HashMap<(ArtiPath, KeyType), Whatever>
  • EDIT: the answer to this lies in KeyMgr, the Keystore does indeed need to be atomic + cross process so an Arc<Mutex<>> internal wrapper is likely the answer here for my use case.
• I'm not sure how this is possible, but it seems KeyMgrBuilder::build() returns a StdResult<KeyMgr, KeyMgrBuilderError>, but KeyMgrBuilderError does not seem to exist anywhere in the source? Guess I'll just ignore the possibility of build() failing for now or just return a generic error in this case? that builder proc-macro is looking a bit sus 👀

Please let me know if the problem is just that I'm holding it wrong 😄

/cc @dan