mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.6 2024-05-09T16:18:23Z 2024-05-09T16:18:23Z Gabriela Moldovan gabi@torproject.org 2024-05-09T16:18:23Z urn:sha1:a9a520f23e793c215d575a33242c22c28e3403cc This is a follow-up from !2131 2024-05-08T17:32:11Z Gabriela Moldovan gabi@torproject.org 2024-05-07T14:17:01Z urn:sha1:453bf8c6c52198f6f51b8190ca42b4432d8f3fd6 2024-05-08T09:54:39Z Gabriela Moldovan gabi@torproject.org 2024-05-08T09:53:25Z urn:sha1:c92a51f83752a7ca80690af84da8943c3a514c71 This updates the keymgr tests to be slightly more robust. These tests attach some metadata to each key, such as the "nickname" of the key (which only exists for testing purposes), whether the key was auto-generated, and the keystore ID of the keystore from which the key was retrieved. Previously, the metadata was encoded in the key "material" itself (the test "keys" were actually just `String`s with a hacky `EncodableKey` implementation that abused the "encrypted" variant of `KeypairData`). This was only possible because we had access to the key internals (through `SshKeyData::Public`/`SshKeyData::Private`), but since the internals are inaccessible now, the tests need to be updated. 2024-05-07T18:43:35Z Gabriela Moldovan gabi@torproject.org 2024-05-07T18:40:34Z urn:sha1:dfb63f8eb8453ae417d2381859cfe7bd213651e5 This helps prevent external users from creating `SshKeyData` out of unsupported types of `ssh_key::public::KeyData` and `ssh_key::private::KeypairData`. 2024-05-07T18:30:54Z Gabriela Moldovan gabi@torproject.org 2024-05-07T15:43:06Z urn:sha1:38233357f3bda9d5b87eabb7ebba38796409742a 2024-05-07T18:18:06Z Gabriela Moldovan gabi@torproject.org 2024-05-07T18:01:08Z urn:sha1:bf91397557891121db6f5ace609c56d5437b7bdc As explained in the docs, this trait should not be implementable outside of the `tor-keymgr` crate. The `SshKeyData::into_erased` and `UnparsedOpensshKey::parse_ssh_format_erased` impls assume the types implementing `EncodableKey` form a statically known closed set. If we later decide to make the supported key types an open set, we should make this trait implementable outside of `tor-keymgr` too. External types wanting to create custom "key types" for use in the keymgr should use the non-sealed `ToEncodableKey` trait, which specifies the `EncodableKey` type to use. This trait is mainly used to create `SshKeyData` IMO, we should make `SshKeyData` opaque, since it's not meant to be constructed through other means (`SshKeyData` is currently a public enum, so its variants and the `ssh_key` types they wrap are public). A future commit will make it opaque. 2024-05-07T13:34:35Z Gabriela Moldovan gabi@torproject.org 2024-05-02T21:53:22Z urn:sha1:2c728593b2b4ea58ea484a1f5a0dc2295d547439 2024-05-07T13:31:45Z Gabriela Moldovan gabi@torproject.org 2024-05-07T11:46:52Z urn:sha1:83119a81eb2ffd67d0608df6b1b2fabbf54401b7 Some of the types and impls from `key_type/ssh.rs` (such as `UnparsedOpenSshKey`) have nothing to do with `KeyType`, and are only used by the `ArtiNativeKeystore`, so I'm moving them to the `arti` keystore module. The shared ssh-related stuff now lives in the top-level `ssh.rs`. 2024-05-07T13:31:45Z Gabriela Moldovan gabi@torproject.org 2024-05-02T21:05:24Z urn:sha1:52bfef4f75709718da592021785b40bbcd6f8a37 This adds an `SshKeyData::into_erased` function that returns the `SshKeyData` as a type-erased concrete key type (e.g. a type-erased `ed25519::Keypair`). This commit duplicates all of the `convert_*` functions from `key_type/ssh.rs`. A future commit will rewrite the code from `key_type/ssh.rs` to use `SshKeyData::into_erased`, and to remove the duplicate functions. Previously, `EncodableKey` returned an encoded `SshKeyData`, which doesn't implement `EncodableKey`. This was rather inconvenient for `Keystore` implementers. For instance, for the in-memory keystore we ended up working around this limitation by serializing and deserializing `EncodableKey`s to and from `String`. For the full context, see https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2076#note_3016460 Needed for #1362 #1367 2024-04-10T01:36:17Z Richard Pospesel richard@torproject.org 2024-04-07T21:49:10Z urn:sha1:062432ff9f4ee7838af6ed1a08a41e181369eb5a