Where does `OsRng` belong?

[dhardy]

Originally posted by @Bluefinger in #1643:

As a third party using rand_core/rand for other projects, I do think something like OsRng belongs to getrandom, since it is exactly the purview of getrandom to provide OS entropy sources. To my brain, the puzzle piece just fits. That said, keeping getrandom lean is another consideration (if seeking to avoid adding features), so an os-rng crate probably would be a good alternative. Being able to depend on smaller, more focused crates is just nicer and preferable, else I'll probably end up rigging up my own OsRng if it means not needing to depend directly on rand if I can help it. However, that might not be too big of a concern, because the main crate I maintain is for a bevy plugin, and bevy already depends on rand anyway...

So all in all, might not actually matter either way. Just yeah, I like smaller crates where possible, but I am not going to lose sleep over it 😄

Reply by @newpavlov:

How about introducing an os-rng crate (or with some other name) and add to it not only OsRng (which I would prefer to rename to SysRng and make OsRng a deprecated type alias), but also ThreadRng behind a crate feature?

It would not only allow us to use ThreadRng without the rest of rand, but also on some platforms OsRng already uses a user-space PRNG (e.g. Windows) and it would be more efficient to use it directly for ThreadRng.

[dhardy]

The way I see it, there is no great cost to having multiple OsRng implementations (rand and os-rng or just getrandom). ThreadRng is quite a lot more code than OsRng.

without the rest of rand,

Without optional dependencies (namely chacha20), rand should be reasonably small a dependency — though it does include quite a bit of code still.

[Bluefinger]

If going the os-rng route, rand could just re-export the implementations as an optional feature. I do like @newpavlov 's suggestion, since that feels like the right split (satisfying a desire for smaller crates when not wanting to use rand directly), while still allowing rand to be more batteries included with various feature options.

[vks]

If we moved OsRng to getrandom, then getrandom would depend on rand_core. I think I would avoid such a circular dependency.

We also used to have rand_os as a separate crate providing OsRng, but IIRC we got rid of it, because people were complaining about too many crates...

[dhardy]

I think I would avoid such a circular dependency.

We can't have a circular dependency — rand_core would not have access to OsRng, though rand would.

This implies that SeedableRng::from_os_rng would not be available (#1674).

---

My primary motivation is that this would put us on a path towards stabilising rand_core. This is more important than rand since the RngCore trait gets used in crate APIs and generators are typically only compatible with one version of rand_core (though technically that is not required, e.g. how winit optionally supports three versions of raw-window-handle).

[tarcieri]

A rand_core v0.10-rc-compatible crate with OsRng is the next blocker for getting all of the @RustCrypto crates switched over to the new prerelease.

I'm fine with some new crate that contains only OsRng, or putting it in getrandom, but either way we need something.

[dhardy]

@tarcieri I published a new pre-release of rand including OsRng. We can also look at other options though.

@newpavlov what do you think about inclusion in getrandom vs an os-rng crate? In the former case rand will obviously depend on getrandom (implying also that breaking releases affect rand). In the latter I'd be tempted just to keep a copy of OsRng in rand.

@vks rand_core has now moved to the core repo. There's no reason getrandom can't depend on it.

[tarcieri]

The biggest problem is rand depends on chacha20 and chacha20 transitively depends on crypto-common which depends on OsRng for keygen