mirrors/arti.git/crates/tor-key-forge, branch arti-v1.4.2mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.22025-03-31T17:59:51ZBump all the unstable tor- and arti- crates to 0.29.0.2025-03-31T17:59:51ZGabriela Moldovangabi@torproject.org2025-03-31T17:34:50Zurn:sha1:1be579f99a7c0784bd7710f9ee6ee9a6b10c85df
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.29.0
done
```
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()`
Upgrade rand dependency to 0.9.2025-03-18T16:09:44ZNick Mathewsonnickm@torproject.org2025-03-17T17:56:27Zurn:sha1:e806f007efb84e40bf17ac1444b35ddab9abc83f
(Per discussion at #1774, we think the changes are acceptable.)
This commit won't compile on its own; subsequent commits will fix it.
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.
Bump minor versions in tor-*, arti-*.2025-03-03T13:18:27ZNick Mathewsonnickm@torproject.org2025-03-03T13:18:27Zurn:sha1:fd4dfef12d55dea0b4c07e290b5fef8cc925cd4dUpgrade to derive_more 22025-02-26T18:06:37ZNick Mathewsonnickm@torproject.org2025-02-26T17:50:42Zurn:sha1:d4dfbd6e1af1935af8cc4b83831891165da6af51
This took a little refactoring, since derive_more::Foo
no longer re-exports std::ops::Foo.
Enable derive-deftly beta features2025-02-12T11:33:27ZIan Jacksonijackson@chiark.greenend.org.uk2025-02-11T16:54:55Zurn:sha1:fd84e2ede87bb63d7312a2e9d4f46ed5c6bdad12
Right now this will give us `${Xmeta as ... default ...}`, which may
improve things in the future.
The Cargo.toml syntax is precisely that from
https://docs.rs/derive-deftly/1.0.0/derive_deftly/doc_changelog/index.html#t:beta
Update to derive-deftly 1.02025-02-12T11:33:27ZIan Jacksonijackson@chiark.greenend.org.uk2025-02-11T16:51:36Zurn:sha1:b3f12ee37c823fb4bcf989b8f7ded5ac3afb02dc
This is released now. Prepared with:
cargo upgrade -i -p derive-deftly
There is some new duplication now I think mostly because pwd-grp uses
old derive-deftly.