Skip to content

fix(deps): update rust crate rand_core to 0.9 #844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ham-renovate wants to merge 1 commit into from
Closed

fix(deps): update rust crate rand_core to 0.9 #844

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion infrastructure/eid-wallet/src-tauri/Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ uuid = { version = "1.0", features = ["v4"] }


argon2 = { version = "0.5.3" }
rand_core = { version = "0.6", features = ["std"] }
rand_core = { version = "0.9", features = ["std"] }
Copy link
Contributor

@coderabbitai coderabbitai bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n infrastructure/eid-wallet/src-tauri/Cargo.toml | head -50

Repository: MetaState-Prototype-Project/prototype

Length of output: 1542

🌐 Web query:

rand_core 0.9 breaking changes API RngCore CryptoRng TryRngCore migration

💡 Result:

rand_core 0.9 (released 2025-01-27) breaking changes & migration notes

1) Fallible RNGs: move try_* methods to the new TryRngCore

  • TryRngCore was added to represent RNGs that can fail (with an associated Error). RngCore now represents infallible RNGs only. For infallible RNGs, TryRngCore is intended to use Error = Infallible. [2]
  • Migration:
    • If your RNG can error: implement TryRngCore (try_next_u32, try_next_u64, try_fill_bytes). [2]
    • If your RNG can’t error: implement RngCore as before and treat fallibility as Infallible when needed. [2]

2) Crypto marker traits: CryptoRngCore replaced by CryptoRng: RngCore; add TryCryptoRng

  • CryptoRng is now a sub-trait of RngCore (replacing CryptoRngCore). For fallible crypto RNGs, use TryCryptoRng (over TryRngCore). [1], [2]

3) SeedableRng constructor renames (common compile break)

  • SeedableRng::from_rng → try_from_rng, and a new infallible from_rng variant was added. [1]
  • SeedableRng::from_entropy → from_os_rng, plus try_from_os_rng. [1]
  • SeedableRng::Seed got extra bounds: Clone and AsRef<[u8]>. [1], [2]

4) Feature / dependency renames that often break Cargo.toml

  • Feature serde1 → serde; feature getrandom → os_rng. [1]
  • MSRV bumped to Rust 1.63; getrandom updated to 0.3.0. [1]

If you share a small snippet of what fails (e.g., your trait bounds / impls), I can translate it to the exact 0.9-style bounds and trait impls.

🌐 Web query:

getrandom 0.3 breaking changes WASM

💡 Result:

getrandom 0.3.0 (released 2025-01-25) changed WASM support in a few breaking ways:

  • wasm32-wasi target removed: switch to wasm32-wasip1 or wasm32-wasip2 instead. [1]
  • Old WASM-related Cargo features were removed: the crate removed the js feature (and also custom, etc.) in favor of configuration flags. [1]
  • New opt-in WASM backend selection model:
    • Enable the backend via the wasm_js Cargo feature. [1][2]
    • Then select it with the cfg flag getrandom_backend="wasm_js" (the feature alone doesn’t select it). [1][2]

Example (for wasm32-unknown-unknown):

# Cargo.toml
getrandom = { version = "0.3", features = ["wasm_js"] }
# .cargo/config.toml
[target.wasm32-unknown-unknown]
rustflags = ['--cfg', 'getrandom_backend="wasm_js"']

Also in 0.3.0, the wasm_js backend dropped a special Node.js codepath, which bumps the minimum supported Node.js to v19. [1]

Sources: [1] [2]

🌐 Web query:

rand_core 0.9 MSRV minimum supported rust version

💡 Result:

rand_core 0.9.x sets rust-version = "1.63" in its published Cargo.toml, so the MSRV is Rust 1.63 (i.e., rustc >= 1.63). [1]

Sources: [1] (docs.rs)

Citations:

🏁 Script executed:

cd infrastructure/eid-wallet/src-tauri && rg "RngCore|CryptoRng|TryRngCore|SeedableRng|OsRng" --type rust

Repository: MetaState-Prototype-Project/prototype

Length of output: 262

🏁 Script executed:

cd infrastructure/eid-wallet/src-tauri && grep -E "^getrandom|rand_core" Cargo.lock | head -20

Repository: MetaState-Prototype-Project/prototype

Length of output: 337

🏁 Script executed:

find infrastructure/eid-wallet/src-tauri -name "Cargo.lock" -o -name "*.toml" | xargs grep getrandom

Repository: MetaState-Prototype-Project/prototype

Length of output: 886

🌐 Web query:

argon2 0.5.3 rand_core 0.9 compatibility

💡 Result:

argon2 0.5.3 is not compatible with rand_core 0.9 (and thus not directly compatible with rand 0.9’s RNG types) because it pulls in password-hash 0.5, which in turn uses rand_core 0.6.4. That creates a different CryptoRng*/RngCore trait version than rand_core 0.9, so types like rand::rngs::OsRng (rand 0.9) won’t satisfy the traits expected by password-hash/argon2. [1][2][3]

What to do:

  • For argon2 0.5.3, use the OsRng re-exported by password-hash (i.e., argon2::password_hash::rand_core::OsRng) so you’re using rand_core 0.6.4 end-to-end. [1][4]
  • If you must standardize on rand_core/rand 0.9 across your project, you’ll need a newer argon2/password-hash release line that also depends on rand_core 0.9 (otherwise you can’t avoid the duplicated rand_core versions). [2][3]

Sources

  1. argon2 0.5.3 Cargo.toml (features + password-hash dep) — https://docs.rs/crate/argon2/0.5.3/source/Cargo.toml.orig [1]
  2. argon2 0.5.3 Cargo.lock showing password-hash 0.5.0 -> rand_core 0.6.4 — https://docs.rs/crate/argon2/latest/source/Cargo.lock [2]
  3. Rand 0.9 migration guide (rand/rand_core 0.9 line) — https://rust-random.github.io/book/update-0.9.html [3]
  4. Discussion of the “multiple versions of rand_core” / OsRng mismatch with argon2 0.5.3 — https://stackoverflow.com/questions/79473286/ [4]

🏁 Script executed:

cd infrastructure/eid-wallet/src-tauri && head -30 src/funcs/mod.rs | grep -A 5 "password_hash\|OsRng"

Repository: MetaState-Prototype-Project/prototype

Length of output: 459

rand_core 0.9 is incompatible with argon2 0.5.3 and creates duplicate trait versions in the build.

The project specifies rand_core = "0.9" (line 32), but argon2 0.5.3 depends on password-hash 0.5, which in turn requires rand_core 0.6.4. This causes both versions to coexist in Cargo.lock (rand_core 0.6.4 and 0.9.3), creating separate trait hierarchies that cannot interoperate.

The code currently works around this by using password_hash::rand_core::OsRng (the 0.6.4 version), which bypasses the specified 0.9 dependency. However, this approach masks the underlying version conflict.

Options to resolve:

  1. Downgrade rand_core to 0.6.4 if rand_core 0.9 is not required by other dependencies.
  2. Upgrade argon2 to a version compatible with rand_core 0.9 (requires investigation into available releases).
  3. Justify the 0.9 dependency if it serves other parts of the codebase; if so, migrate to a compatible password-hashing solution.

Without resolution, the build carries unnecessary trait duplication and the actual rand_core version in use differs from what's declared in Cargo.toml.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@infrastructure/eid-wallet/src-tauri/Cargo.toml` at line 32, rand_core 0.9
conflicts with argon2 → password-hash which requires rand_core 0.6.4, causing
duplicate trait versions; resolve by picking one remediation: either (A)
downgrade the explicit dependency "rand_core" in Cargo.toml from 0.9 to 0.6.4 so
a single rand_core version is used, then run cargo update and replace any uses
of password_hash::rand_core::OsRng with rand_core::OsRng if necessary; or (B)
upgrade argon2 to a release that depends on rand_core 0.9 (if available), update
Cargo.toml to that argon2 version and run cargo update to unify versions; ensure
after the change there is only one rand_core entry in Cargo.lock and remove any
cross-version OsRng usage.

thiserror = { version = "2.0.11" }
tauri-plugin-process = "2"

Expand Down