| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/issues/2436#note_3384773
Made with
nailing-cargo -Eu set-version -p arti-client 0.41.0
nailing-cargo -Eu set-version -p arti-relay 0.41.0
nailing-cargo -Eu set-version -p arti-rpcserver 0.41.0
nailing-cargo -Eu set-version -p arti-ureq 0.41.0
nailing-cargo -Eu set-version -p arti-rpc-client-core 0.41.0
nailing-cargo -Eu set-version -p tor-basic-utils 0.41.0
nailing-cargo -Eu set-version -p tor-error 0.41.0
nailing-cargo -Eu set-version -p tor-general-addr 0.41.0
nailing-cargo -Eu set-version -p tor-geoip 0.41.0
nailing-cargo -Eu set-version -p tor-memquota-cost 0.41.0
nailing-cargo -Eu set-version -p tor-llcrypto 0.41.0
nailing-cargo -Eu set-version -p tor-cert-x509 0.41.0
nailing-cargo -Eu set-version -p tor-rtcompat 0.41.0
nailing-cargo -Eu set-version -p tor-rtmock 0.41.0
nailing-cargo -Eu set-version -p tor-async-utils 0.41.0
nailing-cargo -Eu set-version -p tor-config 0.41.0
nailing-cargo -Eu set-version -p tor-config-path 0.41.0
nailing-cargo -Eu set-version -p tor-rpc-connect 0.41.0
nailing-cargo -Eu set-version -p tor-log-ratelim 0.41.0
nailing-cargo -Eu set-version -p tor-rpcbase 0.41.0
nailing-cargo -Eu set-version -p tor-memquota 0.41.0
nailing-cargo -Eu set-version -p tor-units 0.41.0
nailing-cargo -Eu set-version -p tor-bytes 0.41.0
nailing-cargo -Eu set-version -p tor-protover 0.41.0
nailing-cargo -Eu set-version -p tor-checkable 0.41.0
nailing-cargo -Eu set-version -p tor-cert 0.41.0
nailing-cargo -Eu set-version -p tor-key-forge 0.41.0
nailing-cargo -Eu set-version -p tor-hscrypto 0.41.0
nailing-cargo -Eu set-version -p tor-socksproto 0.41.0
nailing-cargo -Eu set-version -p tor-linkspec 0.41.0
nailing-cargo -Eu set-version -p tor-cell 0.41.0
nailing-cargo -Eu set-version -p tor-persist 0.41.0
nailing-cargo -Eu set-version -p tor-keymgr 0.41.0
nailing-cargo -Eu set-version -p tor-relay-crypto 0.41.0
nailing-cargo -Eu set-version -p tor-proto 0.41.0
nailing-cargo -Eu set-version -p tor-netdoc 0.41.0
nailing-cargo -Eu set-version -p tor-consdiff 0.41.0
nailing-cargo -Eu set-version -p tor-netdir 0.41.0
nailing-cargo -Eu set-version -p tor-relay-selection 0.41.0
nailing-cargo -Eu set-version -p tor-chanmgr 0.41.0
nailing-cargo -Eu set-version -p tor-ptmgr 0.41.0
nailing-cargo -Eu set-version -p tor-dircommon 0.41.0
nailing-cargo -Eu set-version -p tor-guardmgr 0.41.0
nailing-cargo -Eu set-version -p tor-circmgr 0.41.0
nailing-cargo -Eu set-version -p tor-dirclient 0.41.0
nailing-cargo -Eu set-version -p tor-dirmgr 0.41.0
nailing-cargo -Eu set-version -p tor-dirserver 0.41.0
nailing-cargo -Eu set-version -p tor-hsclient 0.41.0
nailing-cargo -Eu set-version -p tor-hsservice 0.41.0
nailing-cargo -Eu set-version -p tor-hsrproxy 0.41.0
|
| |
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/issues/2436#note_3384773
Made with
cargo set-version --offline --bump patch -p safelog
|
| |
|
|
| |
As generated by maint/fixup-features.
|
| | |
|
| |
|
|
| |
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_`).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream `ssh-key` is missing some important features we need for
arti-relay:
* a bug fix without which we can't convert deserialized RSA keys to
their rsa counterparts: https://github.com/RustCrypto/SSH/pull/318
* @wesleyac 's patch https://github.com/RustCrypto/SSH/pull/412 for
allowing insecure (1024 bits long) RSA keys (needed because the
relay KS_relayid_rsa identity keys are 1024 bits long)
We plan to switch back to mainline `ssh-key` when `ssh-key 0.7.0` comes
out.
See the discussion in #2398 for more details.
|
| |
|
|
|
| |
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
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This commit is intentionally misindented to make reviewing the diff a
bit easier.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a certificate's `ArtiPath`, the `ArtiPath` of the subject key is now
separated from the certificate denotators by `@`. This will enable us to
derive the subject key `ArtiPath` from the `ArtiPath` of its
certificate.
In practice, this change is a no-op for the relay implementation,
because none of our certificates have certificate denotators. For
instance, the `ArtiPath` of the for the `KP_relaysign_ed` certificate
(`KP_relaysign_ed` signed with `KS_relayid_ed`) is of the form
`relay/relaysign_ed+<valid_until>` (the only denotators here are the
denotators of the subject key).
It's important to note that the certifying key is not encoded in the
`ArtiPath` of the certificate. The implication is that if we'll ever
need to have multiple certs for the same subject key, signed with
different with different certifying keys, those certificates will be
distinguished by their certificate denotator group. So if we ever need a
second certificate for `KP_relaysign_ed`, certified with something other
than `KP_relaysign_ed`, it will need to be of the form
`relay/relaysign_ed+<valid_until>@<CERT_DENOS>`, where `<CERT_DENOS>`
is a list of `+`-separated certificate denotators.
Closes #2377
|
| | |
| |
| |
| |
| |
| | |
This will enable us to parse certificate paths that consist of the
`ArtiPath` of the subject key, followed by the denotator group of the
certificate.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This introduces the concept of a "denotator group", and new syntax for
separating denotator groups within an ArtiPath.
The implementation will follow in a separate commit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
`KeyCertificateSpecifiers` have an `ArtiPath`, so it's only natural to
retrieve it via this new `KeySpecifier` implementation.
This replaces the old, ad-hoc `ArtiPath` building from the `KeyMgr`
implementation: IMO, the `KeyMgr` impl is the wrong place to build these
`ArtiPath`s (ideally they should remain opaque to the `KeyMgr`).
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Resolves a clippy warning.
|
| | | |
|
| | |
| |
| |
| | |
Resolves a clippy warning.
|
| | | |
|
| | |
| |
| |
| | |
As suggested by clippy
|
| | | |
|