id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
10964	unbound : this should use /dev/urandom rather than /dev/random.	ken@…	ken@…	"Until the fix for CVE-2018-1108 (4.17-rc1, backported to 4.16.4) /dev/random was available early, even if its initialisation had not completed.

Before that fix [https://lkml.org/lkml/2018/4/12/711] unbound started promptly on all of my desktop systems, but after it some machines took two and a half minutes to run the unbound bootscript - keying Ctrl-C a few times, and perhaps <enter>, or just thumping on the keyboard, seems to expedite matters. The affected machines only have SSD drives, but some others with just an SSD continue to start normally (perhaps 5 seconds for unbound to run).

I use unbound to prevent DNS spoofing, IMHO that does not require cryptographic-quality randomness. As noted in [http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-July/080277.html] et seq. unbound appears to try to fallback to /dev/urandom if using /dev/random fails. But /dev/random now correctly hangs until sufficent entropy is available.

And Nixos apparently creates /var/lib/unbound/dev/random and bind mounts /dev/urandom to it. We, at least in sysv, currently re-seed /dev/urandom after unbound has been started.

1.At the moment I have no idea if (on a regular desktop machine) the value returned by an unseeded /dev/urandom is consistent across boots, or if the re-seeding needs to be brought forward (but it appears that either it should be, or else it might not be needed at all, except perhaps on VMs).

2.The more important issue is whether my evaluation of the code in unbound is correct. For this, trying to patch out the use of /dev/random so that it should fallback to /dev/urandom seems to be the first line of approach, even if the Nixos approach turns out to be better for the long term."	enhancement	closed	normal	8.3	BOOK	SVN	medium	wontfix