On Sun, Jun 11, 2017 at 12:06:43PM -0500, Bruce Dubbs wrote: > > Google sez: > > "/dev/random should be suitable for uses that need very high quality > randomness such as one-time pad or key generation. When the entropy pool is > empty, reads from /dev/random will block until additional environmental > noise is gathered. A read from the /dev/urandom device will not block > waiting for more entropy." > > What sysrand.c does is include either "unix_urandom.c" or "unix_rand.c". > > Personally I don't think we should worry about the difference. The best I > can tell, the need for random numbers in nss is only needed when creating a > certificate. Using urandom seems to merely sacrifice randomness for speed. > I'll go with that (unless distros start using the new option). Google found very little about the option, and nothing to explain why it was added (a bug report turned out to be for tracking nss changes in firefox-55, not for nss itself).
By the time firefox starts on a BLFS system there should be enough entropy, even on systemd (which has been fingered as a heavy user of /dev/random) - the problems of lack of entropy seem to be on embedded systems and (perhaps) in distro binary installs. ĸen -- I live in a city. I know sparrows from starlings. After that everything is a duck as far as I'm concerned. -- Monstrous Regiment -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
