| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we have `bounds()`, we can centralise this implementation and
delete the implementations.
I don't think it's necessary to provide an engineered safeguard
against downstreams overriding this method. Any existing implementors
of this trait will break because they must provide `.bounds()` now,
which is an opportunity to notice that the `is_valid_at` can be
deleted. But, if it is not deleted, nothing goes wrong.
|
| |
|
|
|
| |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| |
|
|
|
|
|
| |
This makes a `TimeBound` much more convenient to work with, will allow
more centralisation.
This replaces temporary `bound` inherent method on `TimeRangeBound`.
|
| | |
|
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()`).
|
| |
|
|
|
|
|
| |
This required to add a slight helper to our tor-key-forge RSA key d-d
macro to access the inner keypair. This avoids a clone.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
| |
This currently can't be used due to upstream limitations in the ssh_key
crate, which will be removed likely in the next release. In the
meantime, we can put in all the groundwork.
|
| |\
| |
| |
| |
| | |
tor-key-forge: Add RSA key types.
See merge request tpo/core/arti!3236
|
| | |
| |
| |
| | |
As discussed with gabi on IRC today.
|
| | |
| |
| |
| |
| |
| |
| | |
Some things I'm still considering here:
* We may want to define a tor_llcrypto::pk::rsa::Signature newtype.
* We likely want to rename tor_llcrypto::pk::rsa::PrivateKey to RsaKeypair.
|
| |/
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
```text
warning: doc list item overindented
--> crates/arti-rpc-client-core/src/conn/connimpl.rs:322:9
|
322 | /// indicates that no more messages will be received for this request.
| ^^^ help: try using ` ` (2 spaces)
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_overindented_list_items
note: the lint level is defined here
--> crates/arti-rpc-client-core/src/lib.rs:8:9
|
8 | #![warn(clippy::all)]
| ^^^^^^^^^^^
= note: `#[warn(clippy::doc_overindented_list_items)]` implied by `#[warn(clippy::all)]`
```
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng. This trait helps us enforce that.
We also add a FakeEntropicRng struct to use for testing.
Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
| |
Previously we used the version signature::rand_core for some reason,
but that's now incompatible.
|
| |
|
|
|
|
|
|
|
|
|
| |
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
|
| |
|
|
|
| |
No longer used, because we're now using `ParsedEd25519Cert` instead of
`KeyUnknownCert` to represent parsed but not yet validated certs.
|
| |
|
|
|
| |
This will enable us to retrieve it from the keystore as an `ErasedKey`
(side note, we should rename `ErasedKey` to `ErasedItem`).
|
| | |
|
| |
|
|
| |
We'll soon use this.
|
| | |
|
| |
|
|
|
|
|
| |
This will soon be used, when we modify the `ArtiNativeKeystore` cert
lookup code to actually parse certificates before returning them.
Part of #1768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`KeyUnknownCert` will soon be used as the `ToEncodableCert::ParsedCert`
type for Tor ed25519 certs.
For example, the `ToEncodableCert` impl for `RelaySigningKeyCert` will
look like this:
```rust
pub struct RelaySigningKeyCert(EncodedEd25519Cert);
impl ToEncodableCert<RelaySigningKeypair> for RelaySigningKeyCert {
type ParsedCert = KeyUnknownCert;
type EncodableCert = EncodedEd25519Cert;
type SigningKey = RelayIdentityKeypair;
fn validate(
cert: Self::ParsedCert,
subject: &RelaySigningKeypair,
signed_with: &Self::SigningKey,
) -> Result<Self, InvalidCertError> {
// TODO: validate `KeyUnknownCert`
// and convert it to an EncodedEd25519Cert
// (we don't yet an easy way to perform this conversion)
}
fn to_encodable_cert(self) -> Self::EncodableCert {
self.0
}
}
```
|
| |
|
|
|
|
|
|
| |
This is necessary because `ParsedCert`s will not be `EncodableItem`s.
This is because we cannot (and don't want to) write certificates that
have not yet been validated to the keystore. They do need to be
retrievable from the keystore though, so we also change `ErasedKey`
to be `Box<dyn ItemType>` instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need two different types to represent
* certs that have been parsed, but not yet validated
(`KeyUnknownCert`)
* newly generated encodable certs (`EncodedEd25519Cert`)
Currently, we don't use `KeyUnknownCert` anywhere, and instead use
`EncodedEd25519Cert` to represent "parsed" but not-yet-validated certs.
This approach is wrong and relies on a broken (no-op)
`EncodedEd25519Cert::from_bytes` implementation. A future commit will
address this problem by replacing `EncodedEd25519Cert::from_bytes` with
`Ed25519Cert::decode` to actually parse the cert upon retrieving it from
the keystore.
|
| |
|
|
|
|
|
|
| |
In practice, we won't be able to obtain an `ToEncodableCert` type from
an `EncodableItem` cert without validating it first, so we need to
collapse `validate` into `from_encodable_cert`.
Part of #1768
|
| |
|
|
| |
This will soon be used.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
|
| |
This enables us to get rid of the tor-key-forge -> tor-hscrypto
dependency, partially addressing the TODO from `tor_key_forge::traits`.
This commit is mostly code motion. Best reviewed with `--color-moved`.
See also #1778
|
| |
|
|
|
|
|
| |
We can't possibly know the `ErrorKind` of such an error, unless we know
where the unsupported key came from. Since we can't know this, we should
let a higher level crate (like `tor-keymgr`) decide the `ErrorKind`
instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will enable us to store `tor_cert::EncodedEd25519Cert`s in the
keystore.
|
| | |
|
| | |
|
