On Tue, 2018-05-08 at 15:43 +0200, Guillem Jover wrote: > Hi! > > On Mon, 2018-05-07 at 01:04:26 +0100, Ben Hutchings wrote: > > Source: libbsd > > Version: 0.8.7-1 > > Severity: serious > > Tags: upstream > > The manual page for arc4random_buf() says "High quality 32-bit > > pseudo-random numbers are generated very quickly." This promise is > > false, and it can never be true in general! > > > > On recent Linux kernel versions arc4random_buf() uses the getrandom() > > system call where available. getrandom() is documented to block > > (or return an error, depending on the flags parameter) when > > the kernel's RNG does not have enough entropy available. It was > > recently found that the RNG was unblocking getrandom() too early > > (CVE-2018-1108). > > > > But the fix for this means that getrandom() and arc4random_buf() may > > block until a minute or even longer after boot. Since > > gnome-session-binary calls arc4random_buf() via > > IceGenerateMagicCookie(), fixing the kernel causes a "blank screen" > > regression for some systems. > > > > I don't know quite how we're going to solve this, but at the very > > least the manual page for arc4random_buf() must clarify whether it > > is intended to provide high quality, or non-blocking, behaviour. > > I'll just pull in the latest update from OpenBSD, which seems to have > addresses this problem in Linux: > > > <https://github.com/openbsd/src/blob/master/lib/libcrypto/arc4random/getentropy_linux.c> > > And I've to agree with the comment there, that the behavior in Linux > is less than ideal.
But it is correctly documented. :-) Ben. > (While at it, I'll be checking any other imported files for updates.) > > Thanks, > Guillem -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
