mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.2 2025-03-31T17:59:51Z 2025-03-31T17:59:51Z Gabriela Moldovan gabi@torproject.org 2025-03-31T17:34:50Z urn:sha1:1be579f99a7c0784bd7710f9ee6ee9a6b10c85df Done using: ``` for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do cargo set-version -p $crate 0.29.0 done ``` 2025-03-31T17:59:48Z Gabriela Moldovan gabi@torproject.org 2025-03-31T17:33:52Z urn:sha1:a0919b507bb2a5855e36b85a2e10e3eac5fa4e15 The non-{arti-,tor-} crates are: ``` ./maint/list_crates | rg -v '^(tor|arti)' oneshot-fused-workaround slotmap-careful test-temp-dir fslock-guard hashx equix caret fs-mistrust safelog retry-error ``` We split them in the following categories: * crates with no changes (no version bumps): ``` maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change" | grep -v '\(tor\|arti\)-' oneshot-fused-workaround: No change. slotmap-careful: No change. fslock-guard: No change. caret: No change. retry-error: No change. ``` * crates that only have non-functional changes (bump the patch version): - test-temp-dir - equix - fs-mistrust - safelog * crates where APIs were broken (bump minor): - hashx (`RngCore` impl for `SipRand`) The bumps from this commit were created using this script: ``` PATCH=" test-temp-dir equix fs-mistrust safelog " for crate in $PATCH; do cargo set-version --bump patch -p $crate; done MINOR=" hashx " for crate in $MINOR; do cargo set-version --bump minor -p $crate; done ``` 2025-03-27T14:32:48Z Gabriela Moldovan gabi@torproject.org 2025-03-27T12:15:38Z urn:sha1:fef7fb1e1bc4b7b4c91a3d64b69a9b9690839e41 The `js` feature was replaced by a configuration flag in [0.3.0], so I've checked in a `.cargo/config.toml` for `tor-llcrypto` and `tor-bytes` with `RUSTFLAGS` for selecting the `getrandom` backend to use on wasm32. [0.3.0]: https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md#030---2025-01-25 2025-03-24T19:11:48Z Nick Mathewson nickm@torproject.org 2025-03-24T16:39:41Z urn:sha1:d3ba62b6e9bfa9d138042a062838c65d7fa3ab0f 2025-03-24T19:11:48Z Nick Mathewson nickm@torproject.org 2025-03-20T15:09:08Z urn: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. 2025-03-24T19:10:21Z Nick Mathewson nickm@torproject.org 2025-03-20T14:51:44Z urn:sha1:71ec7a3c6e563c4107ff62ea003794c6a31e45a6 2025-03-24T19:10:21Z Nick Mathewson nickm@torproject.org 2025-03-20T14:26:56Z urn:sha1:ee7c15868e916bc7dbbd26e707077c452dd5d452 This Rng combines inputs from several sources, including OsRng, to minimize the likelihood of falling to a vulnerability in any particular one. 2025-03-18T16:30:25Z Nick Mathewson nickm@torproject.org 2025-03-18T16:30:25Z urn:sha1:5e86cb72edfde43464f6bfacff87616df7df6aea (This applies to every crate that has an API that takes a `rand::Rng` or any related trait.) 2025-03-18T16:09:44Z Nick Mathewson nickm@torproject.org 2025-03-18T14:47:35Z urn:sha1:895bc807f106e359d35522a3ad5f288ba6cf6a9c - The Rng::gen() functions have been renamed to Rng::random(). 2025-03-18T16:09:44Z Nick Mathewson nickm@torproject.org 2025-03-18T13:24:41Z urn:sha1:9e4de6cbfe5cef6076b89f7a94a5232d47b980dd dalek-cryptography is still on rand 0.8, so we need a compatibility shim for the Rng. Fortunately, since we merged interface-abstraction-of-the-daleks (!2868), we no longer need to propagate this compatibility layer throughout our codebase.