Uh oh!
There was an error while loading. Please reload this page.
Use OsRng when generating a new Mnemonic - #105
Conversation
19d4160 to
f464135Comparetankyleo
commented
Aug 6, 2026
I regenerated |
tnull
left a comment
There was a problem hiding this comment.
Looks good, but can we do the dependency bump and the switch to OsRng in two separate commits?
In the following commit, we will switch the default RNG used to generate the `Mnemonic` from `rand::rngs::ThreadRng` to `rand::rngs::OsRng`. The rand 0.7 release shipped `OsRng` with a new constructor, so instead of handling the different constructors across versions 0.6 and 0.7+, we choose to bump the minimum rand version supported to 0.7. To reproduce the new `Cargo-minimal.lock`: ``` mv Cargo-minimal.lock Cargo.lock cargo +1.41.1 update --package "rand" --precise "0.7.0" cargo +1.41.1 update --package "rand" --precise "0.7.0" cargo +1.41.1 update --package "libc" --precise "0.2.151" cargo +1.41.1 update --package "ppv-lite86" --precise "0.2.17" mv Cargo.lock Cargo-minimal.lock ```
`ThreadRng` *should* be fine, but we are paranoid, and we do not need mnemonic generation to be fast, so we prioritize security and use `OsRng` by default to generate a new `Mnemonic`.
f464135 to
87bd59dComparetankyleo
commented
Aug 8, 2026
@tnull I've addressed your comment thank you. I also revisited how I create the new |
tnull
left a comment
There was a problem hiding this comment.
Thanks! LGTM!
Talked to other maintainers in the meantime, and we might be good to bump rand/MSRV even further, but that doesn't need to happen in this PR.
Uh oh!
There was an error while loading. Please reload this page.
ThreadRngshould be fine, but we are paranoid, and we do not need mnemonic generation to be fast, so we prioritize security and useOsRngby default to generate a newMnemonic.Raise the minimum supported rand version to 0.7, the earliest release with unit-style
OsRngconstruction, while preserving Rust 1.41.1 compatibility through the MSRV dependency pins.