On Tue 2019-03-05 18:48:11 +0100, Santiago Vila wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907191
ugh :(
> I'll take a look at the kernel feature to see if it's better than this.
fwiw, the change isn't in the kernel -- it's in how userspace talks to
the kernel to get its entropy. On the Linux kernel, gcrypt 1.8.4
(finally) decided to use the getrandom() syscall when available, rather
than talking to /dev/random, so that should fix everything that uses
libgcrypt for random numbers. So even after the upgrade of gcrypt, it's
possible that other tools are accessing /dev/random via another method,
and they won't be fixed.
I think the right thing to do in those cases is actually to change those
tools to use getrandom() as well. If you've got a list of packages whose
builds fail when /dev/random is blocked, i'd love to see it -- do you
have a list of those bugs other than this one and #850269? This
misbehavior is a good hint for where we need to look in the ecosystem to
fix things. Even better if we could have a special kernel-provided
character device that (by analogy with /dev/zero, /dev/full, or
/dev/null) always blocks indefinitely, then we could just create it as
/dev/random and rebuild the archive to see which packages hang.
For anyone following along on this bug, I recommend reading random(7)
for an overview of the differences between sources of kernel-level
entropy.
--dkg
signature.asc
Description: PGP signature
