Bump rand from 0.8.5 to 0.9.3 #7
No reviewers
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
rust
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
navicore/anz!7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dependabot/cargo/rand-0.9.3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bumps rand from 0.8.5 to 0.9.3.
Changelog
Sourced from rand's changelog.
... (truncated)
Commits
1aeee9fPrepare v0.9.3: deprecate featurelog(#1764)98473eePrepare rand 0.9.2 (#1648)031a1f5examples/print-next.rs(#1647)6cb75eeMake UniformUsize serializable (#1646)0c955c5Add some tests for BlockRng, BlockRng64 and Xoshiro RNGs (#1639)204084aFix: Remove accidental editor swap file (#1636)86262acDeprecate rand::rngs::mock module and StepRng (#1634)a6e217fUpdate statrs link (#1630)db993ecPrepare rand v0.9.1 (#1629)3057641Remove zerocopy from rand (#1579)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.
Code Review: Bump rand 0.8.5 → 0.9.3
Overview
This Dependabot PR upgrades
randfrom 0.8.5 to 0.9.3 (a minor semver bump that includes the breaking 0.9.0 release). The changes are mostly mechanical API updates required by rand's renamed functions, plus one notable workaround for a transitive dependency conflict.What's Done Well
rand::thread_rng().fill_bytes(&mut bytes)withrand::rng().fill_bytes(&mut bytes), which is the proper rand 0.9 equivalent.fill_byteson a CSPRNG, which is appropriate for security-sensitive tokens (CSRF, auth, client secrets).keys.rs: The inline comment clearly explains why a workaround is needed, making this maintainable.Issues & Concerns
1. Fork-Protection Removed in rand 0.9 (Security — Low Risk, Worth Knowing)
rand 0.9.0 removed fork-protection from
ThreadRng:If this server ever forks processes (e.g., via a multiprocess deployment model), child processes could share RNG state with the parent, weakening token randomness. For a typical single-process async server this is a non-issue, but it's worth being aware of.
Recommendation: Confirm the deployment model is single-process. If not, add
ThreadRng::reseedcalls afterfork.2. Dual
randVersions in the Lock File (Maintenance)The lock file now carries both
rand 0.8.5andrand 0.9.3becausejsonwebtokenandrsastill depend on rand 0.8. This doubles the rand/rand_chacha/rand_core/getrandom subtrees and slightly inflates compile times and binary size.Recommendation: Check whether
jsonwebtokenorrsahave newer releases that depend on rand 0.9. If not, this is unavoidable for now — but worth a follow-up issue.3. The
password_hash::rand_core::OsRngWorkaround inkeys.rs(Fragility)The solution to the
ed25519-dalek 2.x/rand_core 0.6vsrand_core 0.9mismatch is clever but indirect — it borrowsOsRngviapassword_hash's re-export ofrand_core 0.6:This works today, but it's an implicit dependency on
password_hash's internal re-export, which could silently break ifpassword_hashupgrades its ownrand_coredependency.Recommendation: Make the dependency explicit by adding
rand_core = "0.6"directly toCargo.toml:This makes the intent clear to future maintainers and avoids hidden coupling. The longer-term fix would be upgrading
ed25519-dalekto a version that supportsrand_core 0.9.Summary
password_hashworkaroundrand_core = "0.6"depThis is a well-handled upgrade overall. The main actionable suggestion is to make the
rand_core 0.6dependency explicit inCargo.tomlrather than borrowing it throughpassword_hash.