On Sun, Jul 21, 2019 at 07:20:08PM +0000, Taylor R Campbell wrote:
> > 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.
I suspect it's the problem. There were several rust processes, all
blocked on /dev/random
>
> 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.
Actually, I have no idea what the requirements for a full pbulk build are
in this area. We'll certainly want to do packages signing at some point.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
