> Date: Sun, 21 Jul 2019 20:52:52 +0200 > From: Manuel Bouyer <bou...@antioche.eu.org> > > /dev/randon actually works as documented and if rust wants /dev/urandom > behavior it should use /dev/urandom. Also I'd like to get explained why > a compiler needs that much random bits.
The difference is that /dev/random may block, and if it blocks, it doesn't wake up until the entropy pool is seeded. In contrast, /dev/urandom never blocks, even if the entropy pool has not yet been seeded. There is no reason in modern cryptography to read more than one byte from /dev/random ever in a single application; once you have done that, or confirmed some other way that the the entropy pool is seeded, you should generate keys from /dev/urandom. What Rust's vendor/rand library seems to guarantee for its callers is that it won't return any data until the entropy pool has been seeded, and then it will return arbitrarily much data without ever blocking again. It does this by reading a single byte from /dev/random, and then generating keys from /dev/urandom. This is _locally_ sensible for a library that may have many users beyond a compiler. But what seems to be happening (although I haven't dived into the build process myself to confirm) is that many subprocesses in the build process are _indepenently_ initializing the Rust vendor/rand library -- reading one byte from /dev/random, which sometimes blocks. In a build chroot, or in a Xen guest, where you aren't handling any secrets (e.g., no sshd except on the local network, no package signing, &c.), you can replace /dev/random by a symlink to /dev/urandom and the build will never block.