| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
feat: Make KeystoreEntry::new() public
See merge request tpo/core/arti!3288
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 6958b6c8 changed the way the `Keystore` trait works.
The `list` method must now return a `KeystoreEntry`. Before this change,
it was essentially impossible to implement keystores outside of
`tor-keymgr`. For 3rd party users of the Arti API that want to implement
a custom keystore, it became essentially impossible to do so.
To make this work again, this commit makes KeystoreEntry::new() public,
if the experimental-api feature is enabled.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
These are unused, and I don't think they're needed by our API users
either, since `KeystoreEntryResult` is just a type alias for `Result`.
|
| | | |
|
| | |
| |
| |
| | |
`RawKeystoreEntry` no longer exists, so these tests need to be updated.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I think this adds unnecessary indirection, and it's a bit confusing to
have two separate keystore entry types (we have `KeystoreEntry` too).
This type exists just to server as a wrapper over the `RawEntryId` of an
unrecognized keystore entry, and the `KeystoreId` of the keystore it was
found in.
This commit folds `RawKeystoreEntry` into `UnrecognizedEntry`, which was
previously a thin wrapper over `RawKeystoreEntry`.
|
| | |
| |
| |
| |
| |
| | |
Change all call sites.
This completes the rename.
|
| | |
| |
| |
| |
| | |
This updates some outdated references from back when `derive-deftly` was
called `derive-adhoc`.
|
| | |
| |
| |
| |
| | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3891#note_3395849
|
| | |
| |
| |
| | |
This updates a doc and the corresponding test.
|
| | | |
|
| | |
| |
| |
| | |
This also makes the macro `beta_deftly`.
|
| | |
| |
| |
| |
| |
| | |
I want to make all uses of `keypair_specifier` unquoted, so this can't
be a `token_stream` (and in fact, `keypair_specifier` was always meant
to be a type).
|
| | |
| |
| |
| | |
This attribute is called `keypair_specifier`, not `key_specifier`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug that was causing the ephemeral keystore to retrieve
certs in a format that couldn't be handled by the `KeyMgr`. This caused
all certificate retrievals from `EphemeralKeystore` done via the
`KeyMgr` to fail with an internal error.
For context, the only supported cert type is `TorEd25519Cert`, which is
a pre-encoded certificate (i.e. a type wrapper over a `Vec<u8>`).
These certificates are stored as-is by the Arti native keystore (the
bytes are written to a file on disk). When retrieving a
`TorEd25519Cert`, the Arti keystore uses `parse_certificate_erased()` to
parse the cert into a `ParsedEd25519Cert` before returning it as a
type-erased `ErasedKey`. This works as intended with the `KeyMgr`
retrieval and downcasting logic, which expects the certificate to be
returned in the `ParsedCert` format specified in the `ToEncodableCert`
implementation.
Before this change, the ephemeral keystore, on the other hand, did not
play well with the `KeyMgr` when it came to cert retrieval: it would
incorrectly store the `KeystoreItem` as-is, and retrieve it as an
`ErasedKey` using the `ErasedKey::into_erased()` implementation. This
would then cause the `KeyMgr` to fail to downcast the `ErasedKey` to the
correct type (because the returned erased item was of a different type
than `ParsedCert`).
This commit also removes `KeystoreItem::into_erased()`, which was a
footgun (because certificates are not actually supposed to be retrieved
in the format returned by `CertData::into_erased()`).
|
| | | |
|
| | |
| |
| |
| | |
Typos found with codespell
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This moves the logic for retrieving a public key from its corresponding
keypair into `get_from_store()`.
Fixes a bug which made it impossible to retrieve a public key using the
key specifier of its keypair type with any function other than
`KeyMgr::get()`.
|
| | |
| |
| |
| | |
This will be fixed in the next commit.
|
| | | |
|
| | |
| |
| |
| | |
I am about to repurpose this test helper for other item types too.
|
| | | |
|
| | |
| |
| |
| | |
This will enable us to test the provenance of public keys.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is needed now that `get_or_generate_key_and_cert()`
uses the keypair specifier when generating the subject key.
Without this the cert retrieval tests fail because
`get_or_generate_key_and_cert()` now requires the subject key specifier
to have an associated keypair specifier ("KeyCertificateSpecifier has no
keypair specifier for the subject key?").
Note that even with this patch, the `get_cert_entry()` test still fails
because of a bug in the `get_*()` family of functions. This will be
fixed in a future commit.
|
| | |
| |
| |
| |
| |
| |
| | |
When generating a new keypair, we want to use the keypair specifier of
the subject key. Fixes a bug where this code was incorrectly generating
a keypair using the specifier of the public key type (the resulting
generated key had a `kp_` prefix instead of `ks_`).
|
| | |
| |
| |
| |
| | |
This tests that the `KeyMgr` returns an error if you try to retrieve an
invalid cert.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a bit of a hack, but we need it to make the tests pass.
The issue is that our test keystore stores `TestItem`s, and all our
other test used `TestItem` as their key types. Now that we have certs,
we have this concept of a `ToEncodableCert::ParsedCert`, which is what
the keymgr downcasts the retrieved certs to before validating them and
returning the final cert result (which is usually going to be of a
different type than `ParsedCert`).
This wrapper ensures that the keystore returns the expected `ParsedCert`
type, so that validation doesn't fail.
Before this change, we were hackily returning `TestItem` in the tests,
even for certificates, but that doesn't work anymore, because the
`ItemType` impl of `TestItem` returns `KeyType::Ed25519Keypair`, which
is obviously not a `CertType`. Using it resulted in an error because
there is a mismatch between the cert `ItemType` (`Ed25519Keypair`) and
the `ItemType` of the `KeystoreItem::Cert` entry (`Ed25519TorCert`).
Normally this wouldn't happen, but the whole test keystore
implementation is funky and inconsistent.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will enable us to test against other keymgr APIs (e.g.
`list_matching()`), which require some extra trait impls that get
generated for free by our new `CertSpecifier` macro.
|
| | | |
|
| | |
| |
| |
| | |
This will soon be used by other tests too.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will enable us to retrieve a cert given its `KeystoreEntry`. This
is useful for retrieving certificates listed with
`KeyMgr::list_matching()`.
|
| | |
| |
| |
| | |
This was replaced by the new `CertSpecifier` d-d macro.
|
| | |
| |
| |
| |
| | |
This will replace the `has_certificate()` attr from the
`KeySpecifier` d-d macro.
|
| | |
| |
| |
| | |
This will soon be used for parsing the denotators of cert paths too.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We need to be able to parse KeyPaths into KeyCertificateSpecifier,
and we can't do that if the signing key is part of the cert specifier
(because the signing key doesn't get encoded in the key path, unlike the
subject key, which does)
|
| | |
| |
| |
| |
| | |
These are significantly different from `KeySpecifierPattern`s, so it's
best to have a separate trait.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
keymgr: Update cert ArtiPath building to use denotator sets
Closes #2377
See merge request tpo/core/arti!3754
|
| | | |
| | |
| | |
| | | |
Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3754#note_3361904
|
| | | | |
|
| | | | |
|