| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
There is no reason for these to consume self.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
These are the methods which we'd like to give new options in #1746;
we can move other methods later if we want to.
|
| | |
| |
| |
| |
| | |
We're going to move functionality and configuration functions here
to implement #1746.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
There is no need for validation here. If any validation is required, it
will be handled by the calling code.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2672?commit_id=10845d5e6a06d4d9548d536846eb470128d8a7d4#note_3147517
|
| |
|
|
|
| |
No longer used, because we're now using `ParsedEd25519Cert` instead of
`KeyUnknownCert` to represent parsed but not yet validated certs.
|
| |
|
|
|
|
|
| |
This helps us get rid of our uses of `KeyUnknownCert`. Needed because
`KeyUnknownCert` can't readily be converted back to `EncodedEd25519Cert`
(while `ParsedEd25519Cert` *can* -- see the `certs` module from
`tor-relay-crypto`).
|
| | |
|
| |
|
|
|
|
|
| |
This will come in handy later on, when we start using these function in
conjunction with `KeyMgr::get_or_generate_key_and_cert`, which expects
the `make_certificate` callback to return a type that implements
`ToEncodableCert`.
|
| |
|
|
| |
Closes #1777
|
| |
|
|
|
|
| |
These will be the `ToEncodableCert`s we write to the keystore.
Part of #1777
|
| |
|
|
|
| |
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 enable us to deserialize byte slices as `EncodedEd25519Certs`.
Needed because this type will be used to representing a parsed + validated
cert retrieved from the keystore.
Technically, we *could* do without this function by defining a separate
newtype wrapper over `Vec<u8>` to represent the validated cert data, but
IMO adding a second encoded ed25519 cert type in another crate might be
confusing later down the line (because the two types will be nearly
identical, and are bound to eventually diverge in terms of API and
implementation).
Part of #1137
|
| |
|
|
|
|
| |
This updates and reenables the cert management tests.
Part of #1768
|
| | |
|
| |
|
|
| |
Part of #1768
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
I don't think we'll ever need this. Users will set the directories
through the config file.
|
| |
|
|
|
| |
This is probably not what the final logger would look like, but it's a
fine placeholder for now.
|
| | |
|
| |
|
|
| |
This makes it more similar to arti.
|
| | |
|
| | |
|
| |
|
|
| |
We don't actually use it yet, but we do show it in the '--help' text.
|
| | |
|
| |
|
|
|
|
|
| |
This is a bunch of boilerplate code that we don't currently need, and
may not need in the future since we don't need to provide a lot of
library-API-level customization for `TorRelay` like we do with
`TorClient`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is an override option, which we want to default to "unset".
|
| | |
|
| | |
|
