If it's faster, fully API compatible, and maintains all the same guarantees, why isn't the implementation being upstreamed to crypto/rand?

Edit: Looked at the code. It's a little read-ahead cache wrapped around crypto/rand. Good idea! I can't help but wonder if this actually does have some security implications, since rand data is going to be sitting around in process memory potentially long before it's actually requested.

The readme says:

> Maintains all cryptographic security guarantees of crypto/rand

I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.