Tracker: rand v0.10

[dhardy]

Summary

• Bump MSRV to 1.85 (also Edition 2024)
• Wait for getrandom v0.3.4
• Release rand_core v0.10
• Wait for chacha20 v0.10 release (@tarcieri)
• Replace rand_chacha with chacha20 (draft: Adapt to chacha20 #1642; closes Replacing rand_chacha with chacha20 #934)
• Release rand v0.10 using rand_core v0.9.x v0.10

Motivation

#934 and #1574 provide motivation for the switch to chacha20.

The MSRV bump is required by chacha20; releasing this as rand v0.10 not v0.9.x makes the MSRV bump less problematic and the significant change in dependency more transparent.

Not making a breaking release for rand_core makes the transition to rand v0.10 easier for users: RngCore/CrpytoRng/... implementations and bounds will be compatible across rand v0.9 and v0.10.

Alternatives

No CSPRNG (by default)

OsRng (i.e. the OS getrandom / ... interfaces) is fast enough for many use-cases already, so not everyone actually needs a thread-local in-process CSPRNG. #1545 proposes this.

No CSPRNG at all

We could go even further and completely drop ThreadRng, but I don't see much incentive over #1545 (the main one being simplicity).

[dhardy]

Rand v0.10.0-rc.0 is now released using chacha20.

There will likely be further breaking changes before v0.10.0 final.

[dhardy]

getrandom v0.3.4 is released; changes did not require a breaking release. As such, we can go ahead using the existing rand_core v0.9.3 or we can release v0.10.0 (see discussion in #1660).
Significant changes to rand_core include #1641 and #1665.

@tarcieri does this affect your plans for chacha20?

[arielb1]

Could you put the RngCore and CryptoRng traits in a separate crate that rand depends on, so that RngCore 0.9 and RngCore 0.10 are the same trait, to avoid annoying everyone?

Or make rand-core 0.9.4 re-export the non-SeedableRng traits from rand-core 0.10, which would similarly avoid the breakage.

It's probably worth surveying how many people use RngCore in trait bounds vs. SeedableRng.

[dhardy]

That is why rand_core is a separate crate in the first place. Since SeedableRng is a trait that RNGs need to implement directly it is also in rand_core and since we want to provide SeedableRng::from_os_rng(), we need OsRng and a getrandom dep in rand_core.

Arguably the correct approach is to move from_os_rng to a new trait SeedableRngExt in rand or remove it altogether, then move OsRng to rand::rngs.

In the mean-time, we could just continue using rand_core v0.9.x (though annoyingly I already merged #1641 to master).

[tarcieri]

We're close to being ready to release. I think @newpavlov is just trying to finish one last thing up.

One thing we could do is release chacha20 without cipher support and then add that back in a patch release, which would avoid having to get the rest of our crates out first. I imagine having to do another rand_core upgrade there might take a bit.

[arielb1]

That is why rand_core is a separate crate in the first place. Since SeedableRng is a trait that RNGs need to implement directly it is also in rand_core and since we want to provide SeedableRng::from_os_rng(), we need OsRng and a getrandom dep in rand_core.

If you are releasing rand-core 0.10, with whatever changed version of SeedableRng you are making, you should make rand-core 0.9.4's RngCore and CryptoRng traits refer to it using the semver trick.

[newpavlov]

Arguably the correct approach is to move from_os_rng to a new trait SeedableRngExt in rand or remove it altogether, then move OsRng to rand::rngs.

As I argued long time ago, I think it's worth to define OsRng (and its panicking counterpart) in a separate crate (in the past I registered os-rng for this purpose).

@arielb1
I am not sure it's worth to bother with semver trick in our case. It would break our MSRV guarantees and IIUC it would not work if we are to change the SeedableRng API.

[arielb1]

I am not sure it's worth to bother with semver trick in our case. It would break our MSRV guarantees

Are you planning to increase the MSRV of rand-core, not just the MSRV of rand? Why?

and IIUC it would not work if we are to change the SeedableRng API.

With my proposal, you'll have different SeedableRng traits for 0.9 and 0.10, but the same RngCore trait, so users that only use RngCore will not be broken

[newpavlov]

Are you planning to increase the MSRV of rand-core, not just the MSRV of rand? Why?

Primarily to relax our MSRV policy, allow MSRV bumps in patch releases, and to be consistent across crates.

With my proposal, you'll have different SeedableRng traits for 0.9 and 0.10, but the same RngCore trait, so users that only use RngCore will not be broken

I don't think this case is important enough.

[arielb1]

Can't rand-core have a fixed, low MSRV?

[newpavlov]

Can't rand-core have a fixed, low MSRV?

It could. But I believe it's better to be consistent across crates and to allow for more flexibility in future.