Integration into std

[dhardy]

It has been proposed to include roughly this code into the std lib. This is an issue to summarise the proposal and track future development.

Draft RFC: https://github.com/dhardy/rfcs/blob/system-random/text/0000-system-random.md

Discussions:

• ThreadRng / EntropyRng improvements rand#579
• OsRng crate? (or optional PRNG dependencies) rand#648

[tarcieri]

I think it'd be nice to have something that no_std users can also leverage (even if gated behind a nightly-only feature flag), although that might be out-of-scope for this particular RFC.

"Isn't that what the rand crate is for?" you might ask? Well I'm thinking something a little global_allocator perhaps. Here's a handwavy example:

// If this seems too hard to stabilize, feature gate it?
#[feature(global_rng)]

#[global_rng]
pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {
    [...]
}

The idea being that embedded packages can plug in a proprietary global RNG.

I'd love to use getrandom for cryptography projects, but there needs to be a way for these projects to support no_std. I've started switching to getrandom on my std-dependent projects, but I'm hesitant to do so on my projects which support no_std for these reasons.

[dhardy]

If getrandom remains as a crate, this isn't too hard: I proposed a couple of solutions in #4.

On the other hand, if this were integrated into the standard library, it would need to be included in core as a wrapper around some inner function like you listed. I'm not really sure how much sense this makes and don't have much interest in pushing for integration myself.

(Note: in both cases, another crate implementing some kind of entropy pool may be needed to implement getrandom_inner with the limited functionality available on some platforms.)

[newpavlov]

IIUC with inclusion into core we will not need a separate inner function. getrandom function can be a weak lang item (akin global allocator), which will have an always erroring default implementation overwritable by applications.

I think it will be reasonable to first start with #4 and move with std inclusion RFC later.

[tarcieri]

@newpavlov yeah, something to the effect of a lang item was exactly what I was thinking, but I'm not really aware of the difficulty involved in adding a new one, and I know a lot of people think there are too many already

[newpavlov]

Closing in favor of rust-lang/rust#62079.