| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I don't think it's all wrong, this was left over from the first draft
implementation.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, `select_vanguard` returned a `NoSuitableRelay` error if
it was unable to select a relay to use as a vanguard.
We now distunguish the "there are no suitable relays in the vanguard
sets" (`NoSuitableRelays`) error case from the "our vanguard sets are
empty" (`BootstrapRequired`) one.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is about to grow another variant, so I'm moving it to a dedicated
`err` module.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `match` below it is fine, there's no need to rewrite it.
(I think this TODO is actually dupe of the the TODO above it).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I think it's alright to keep it: it gives us the flexibility to extend
it later on, if needed.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This TODO doesn't really need to be implemented: we can test the
`VanguardMgr` just the same without it (`GuardMgrInner` is similar, in
that it doesn't mock the rng).
|
| | | | | | | |
|
| | |/ / / / |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-keymgr: Fix nightly warnings.
See merge request tpo/core/arti!2141
|
| |/ / / /
| | | |
| | | |
| | | | |
This is a follow-up from !2131
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Refactor code shared between ArtiNativeKeystore and ArtiEphemeralKeystore
Closes #1362 and #1367
See merge request tpo/core/arti!2131
|
| | | | |
| | | |
| | | |
| | | | |
This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77.
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This helps prevent external users from creating `SshKeyData` out of
unsupported types of `ssh_key::public::KeyData` and
`ssh_key::private::KeypairData`.
|
| | | | |
| | | |
| | | |
| | | | |
KeyData/KeypairData.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `ssh_algorithm()` function was only meant for use in the
ArtiNativeKeystore, for extracting the `KeyType` given the
`SshAlgorithm` of a key read from disk, so it really shouldn't be
crate-public.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Inserting a key that has the wrong key type no longer fails, because we
now store the `KeyData` as-is, without attempting to parse it as a
specific kind of SSH key.
|
| | | | |
| | | |
| | | |
| | | | |
Closes #1362 #1367
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I think it makes more sense for parse_ssh_format_erased to be a function
of the key than of `KeyType`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We're about to need it in the `UnparsedOpenSshKey` impl.
This commit is just code motion and has no functional changes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`UnparsedOpenSshKey` was originally only meant to be used for the
`ArtiNativeKeystore`.
I am about to make it private to the arti module, so I'm updating the
ephemeral keystore tests to not use it.
Part of #1362
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Use add_warning to maintain warning exception in examples.
See merge request tpo/core/arti!2132
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is the same as the TEST_LINTS exception list, plus the
nightly exception from our main lints list. It matches what
we have in crates/examples/*.rs.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This keeps our begin/end lines consistent, and lets us add new lists.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix remaining instances of unexpected_cfgs lint
Closes #1395
See merge request tpo/core/arti!2134
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
(We need this to permit our usage of our $omit_from hack.)
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
By removing 'cfg(fuzzing)', this resolves another case of #1395.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The use of cfg(fuzzing) here is reasonable and localized, but we
need to permit it to avoid a warning from #1395.
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
This now generates an error (per #1395), and everything we used it for
is also available as a feature.
|