Bugzilla Bug 118054

As the title says, please enable the urandom USE flag by default. The flag was
added as part of the resolution of bug 102587 and is good enough for the vast
majority of users.

Don't see the point, just set the use flag and go on. Besides, it's not
possible on per-ebuild basis until Bug 61732 is fixed and a use flag used by
just two ebuilds in portage makes no sense in make.defaults.

This causes problems in several applications, most prominently Apache and
Subversion. Worse, the programs simply appear to hang and then work at random
(hah) unless you take the time to debug.

How about:
1) adding warnings for now, to make it more obvious, and
2) marking this suggestion as dependant on bug 61732

The alternatives, that I know of, are:
1) adding urandom to make.defaults (silly, I agree)
2) changing urandom to no-urandom (not pretty, against policy)
3) remove the urandom USE flag entirely (-urandom should be rare)
4) make no changes within Gentoo (not friendly)

(In reply to comment #2)
> This causes problems in several applications, most prominently Apache and
> Subversion. Worse, the programs simply appear to hang and then work at random
> (hah) unless you take the time to debug.

Honestly, I'd really like to find out why the heck does Gentoo/Gentoo kernels
have such issues with entropy instead. Are you able to reproduce the problem
with vanilla-sources?

Created an attachment (id=76412) [details]
Lame warning approach

I agree that actually fixing the entropy problem would be nice. For now, here's
a warning.

I was having trouble with 2.6.14-ck5 . I compiled and booted 2.6.15 vanilla,
and was able to drain it of entropy using
cat /dev/random | less
(afterwards, there's little to no entropy in the pool according to cat
/proc/sys/kernel/random/entropy_avail). Starting and aborting an emerge
mozilla-firefox filled it up nicely. The experiment went similarly with
ck-sources.

As for obvious differences, drivers/char/random.c is identical between the two
and grep doesn't find any mention of the random.c interfaces (functions) in the
patch.

(In reply to comment #4)
> I was having trouble with 2.6.14-ck5 . I compiled and booted 2.6.15 vanilla,
> and was able to drain it of entropy using
> cat /dev/random | less
> (afterwards, there's little to no entropy in the pool according to cat
> /proc/sys/kernel/random/entropy_avail). Starting and aborting an emerge
> mozilla-firefox filled it up nicely. The experiment went similarly with
> ck-sources.

Heh well, not exactly a test I had on my mind. :-) I meant whether you are e.g.
able to reproduce the apache "hang" on (re)start with mod_auth_digest enabled
(or some other normal server usage) with other kernel patchsets. The test you
mentioned will of course drain the entropy pretty reliably anywhere. The issue
here is that people tend to run out of entropy even on pretty busy servers, no
idea why, and even just a couple of apache restarts makes it "hang" for many
minutes.

Sorry, this is something we're not going to do. urandom support was added as a
workaround for systems that are having entropy problems, and we don't want
users to use this unless they have to. On most systems, apache works fine using
/dev/random. This is for the systems it does not work on. /dev/random is a more
secure random device and should be used if at all possible.

(In reply to comment #5)
> Heh well, not exactly a test I had on my mind. :-) I meant whether you are e.g.
> able to reproduce the apache "hang" on (re)start with mod_auth_digest enabled
> (or some other normal server usage) with other kernel patchsets. The test you
> mentioned will of course drain the entropy pretty reliably anywhere. The issue
> here is that people tend to run out of entropy even on pretty busy servers, no
> idea why, and even just a couple of apache restarts makes it "hang" for many
> minutes.
> 
I started to do that and realized that I needed to recompile the stack without
urandom and then test again ;) I just took the time to run the
restart-apache-a-lot test and can (with both kernels) exhaust /dev/random for
2-15+ seconds, even with an emerge running.