mirrors/arti.git/crates/tor-key-forge/src, branch arti-v1.4.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.62025-07-07T15:50:04ZTemporarily suppress mismatched_lifetime_syntaxes.2025-07-07T15:50:04ZGabriela Moldovangabi@torproject.org2025-07-07T15:50:04Zurn:sha1:a11b611466a5a73f5e06a0aabd17284a57d12fe3
See #2060.
fix `clippy::doc_overindented_list_items`2025-04-03T17:32:58ZSteven Engleropara@torproject.org2025-04-03T17:21:49Zurn:sha1:663339ffa8bd00ce59c2dd39c288d338505263c3
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)]`
```
Use an EntropicRng trait to enforce key generation rules.2025-03-24T19:11:48ZNick Mathewsonnickm@torproject.org2025-03-20T15:09:08Zurn:sha1:8a33afe155e9bd29d9302b4b44dd5843d00866db
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.
squash! Upgrade rand dependency to 0.9.2025-03-18T16:09:44ZNick Mathewsonnickm@torproject.org2025-03-18T13:01:31Zurn:sha1:2f8993c22c2b86010e4fd8b5169ef0ab83f8c754
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
key-forge: Use CryptoRng from rand.2025-03-18T16:09:44ZNick Mathewsonnickm@torproject.org2025-03-18T14:04:36Zurn:sha1:a71a64ff790c9a9aefdd622ac9d569eddae36ac0
Previously we used the version signature::rand_core for some reason,
but that's now incompatible.
Wrap ed25519-dalek types.2025-03-18T12:45:28ZNick Mathewsonnickm@torproject.org2025-03-17T18:31:42Zurn:sha1:d50e945a5286d89d75892878ff3aa9ed7ebed1f7
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.
tor-key-forge: Remove no longer needed ItemType impl for KeyUnknownCert.2025-01-13T19:29:19ZGabriela Moldovangabi@torproject.org2024-12-12T16:43:18Zurn:sha1:d87d11c7a83b158bdb3ea52ff545462a5a5278c0
No longer used, because we're now using `ParsedEd25519Cert` instead of
`KeyUnknownCert` to represent parsed but not yet validated certs.
tor-key-forge: Implement ItemType for ParsedEd25519Cert.2025-01-13T19:28:23ZGabriela Moldovangabi@torproject.org2024-12-12T13:58:43Zurn:sha1:beacb0a729f1c598b2386a4ddbea88dc7f8aa9d8
This will enable us to retrieve it from the keystore as an `ErasedKey`
(side note, we should rename `ErasedKey` to `ErasedItem`).
tor-key-forge: Add wrappers for various cert types.2025-01-13T19:28:23ZGabriela Moldovangabi@torproject.org2024-12-12T13:58:37Zurn:sha1:e3bcf444252c248a47482f703918ce35d5a663ector-key-forge: Fill out the InvalidCertError type.2025-01-13T19:28:21ZGabriela Moldovangabi@torproject.org2024-12-12T17:00:36Zurn:sha1:88927e965a93ba9153a33068d2a04f2704b092aa
We'll soon use this.