Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

I had a problem with creating new subversion repositories on lark.  It turned
out that /dev/random didn't produced new random any more.  Somehow there was too
few entropy.

The problem is that dev-libs/apr are built with /dev/random-support.  But in
most cases it should be okay to build with /dev/urandom-support.  Therefore the
ebuild needed to be changed.  Probably /dev/urandom should become default or
make it a use-flag.

I vote for /dev/urandom; 
 
any objections? chipig/hollow/stuart/kloeri/...? 

I'm for /dev/urandom. I've run into this issue myself and had to find ways to
get more entropy for /dev/random.

Though the downside is that /dev/urandom is more predictable. Maybe this could
be controlled by a use-flag?

would be an alternative, and, at least _better_ than leaving as-is 
 
cyrus-sasl already has a local useflag "urandom" we might us there as well, in 
case we decide for the `useq erandom` solution 

Created an attachment (id=66784) [details]
patch to use urandom instead of random

Please merge this ASAP.  The use of /dev/random causes serious headaches with
Apache.  The Apache ebuilds use /dev/urandom anyway.

Created an attachment (id=66877) [details]
patch to allow selection of random device

Adds a USE flag "no-urandom".  Default is to use /dev/urandom to avoid blocking
Apache on startup.  USE="no-urandom" will change that to /dev/random, which is
cryptographically better but can cause problems.

I'll look into a fix for this Friday night.

I've added a USE-flag, urandom (because we don't like no-* USE-flags, and
because another package already uses the same flag) that when enabled will use
/dev/urandom instead of /dev/random. The new ebuild is apr-0.9.6-r4. Please test
and see if it works for you.

Thanks!

*** Bug 106834 has been marked as a duplicate of this bug. ***

*** Bug 107449 has been marked as a duplicate of this bug. ***

I just experienced apache hanging for 12 minutes while restarting for
generating
digest stuff.  sys-apps/rng-tools I installed at Marquel (#gentoo-apache)
suggestion and that caused apache2 to start up immediately.  I've seen this
behaviour for quite a while, but today was the longest period that it did not
fully start.

seemant: if you can reproduce the waiting, can you look at
/proc/<processID>/fd/
and see which random device it's blocking on? Adding urandom to USE for
dev-libs/apr (and using apr-0.9.6-r4, which isn't in arch yet, just ~arch) and
recompiling apr, apr-util, apache, and any modules you have should make it use
/dev/urandom instead of /dev/random. (On a side note, I do not know if you need
to recompile all of that, or just apr, best to be safe and do it all)

Also, as a workaround, you can remove the line for auth_digest_module from
httpd.conf - most people don't use that digest method.

This simply does not work w/ apache. I had to emerge emerge sys-apps/clrngd to
work around this bug because I need digest authentication.

It does work for me, and I did an strace to verify it (it's reading
/dev/urandom) 

For those of you that it isn't working, please run an strace and see what
random
device it's using. If it's still using the wrong device, please rebuild the
entire stack, after verifying that you have the urandom USE-flag set. The stack
includes dev-libs/apr-0.9.6-r4 (currently ~arch) dev-libs/apr-util, and
net-www/apache.

I haven't heard any other feedback on this, I can't reproduce it not working.
If
anyone else can reproduce it after rebuilding thier apache stack, please reopen
this bug.

*** Bug 113284 has been marked as a duplicate of this bug. ***

While the urandom flag is useful, it does not solve the problem at all, because
it's not on by default and most users are not aware of the whole issue, first.
We just got caught by this same problem because you leave /dev/random on by
default nor you ewarn advice about risks.
The point of no-urandom use flag, as requested before, is that it makes
/dev/urandom default. Even if it's not elegant, the other way is leaving us
with a "broken" installation, which may stop working without users doing
something
wrong and using absolutely common sense default configuration.
Even net-www/apache itself defaults to urandom, period. How many have to waste
time down the same painful way leading to strace before it's worth an
indoubtely unelegant but working solution?

This is a *corner* case, specific to gentoo, probably specific to one or two
certain kernel lines. Gentoo is not in the practice of making things less
secure because a minority amount of users have a problem with thier kernel - a
problem that can be worked around in much better ways then using /dev/urandom.
There are entropy deamons out there that help /dev/random fill - that is the
solutions most users should use.

(In reply to comment #17)
> This is a *corner* case, specific to gentoo, probably specific to one or two

This is a common case, well documented, which is going to happen to almost
everyone running a server without taking extra steps. Did you care to search
the gentoo forums, there are at least 5 posts about this issue with apache. 


> certain kernel lines. Gentoo is not in the practice of making things less
> secure because a minority amount of users have a problem with thier kernel - a

Gentoo, as any other distro out there, is in the practice of giving working
things and "then" make sure they're secure, and that's what the vast majority
of developers do. urandom may not be the safest solution but it's usually
enough and it does always work. evidence can be found just grepping around:

GLSA from /usr/portage/metadata/glsa/glsa-200311-01.xml:
Secondly, KDM uses a weak cookie generation algorithm.  Users are advised to
upgrade to KDE 3.1.4, which uses /dev/urandom as a non-predictable source of
entropy to improve security.

-Qmail from /usr/portage/mail-mta/qmail/files/mkservercert:
dd if=/dev/urandom of=${randfile} bs=64 count=1 2>/dev/null

-Bind from /usr/portage/net-dns/bind/bind-9.3.2.ebuild:
einfo "Using /dev/urandom for generating rndc.key"
/usr/sbin/rndc-confgen -r /dev/urandom -a -u named

-Pdns from /usr/portage/net-dns/pdnsd/pdnsd-1.2.3.ebuild:
[ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom"

-Openldap from /usr/net-nds/openldap/files/gencert.sh-2.2.27:
dd if=/dev/urandom of=$randfile count=1 2>/dev/null

-Mod_ssl from /usr/portage/net-www/apache/files/2.0.49/40_mod_ssl.conf:
This means you then cannot use the /dev/random device because it would lead to
very long connection times (as long as it requires to make more entropy
available). But usually those platforms additionally provide a /dev/urandom
device which doesn't block. So, if available, use this one instead. Read the
mod_ssl User Manual for more details.

-Apache ebuild from /usr/portage/net-www/apache/apache-2.0.54-r31.ebuild:
 --with-devrandom=/dev/urandom \

-Courier IMAP from /usr/portage/net-mail/courier-imap/files/mkpop3dcert:
dd if=/dev/urandom of=$randfile count=1 2>/dev/null

-Various VNC from /usr/portage/net-misc/vnc/files/vnc-4.0/vnc-cookie.patch:
PID and part of the encrypted form of the password.  Ideally we'd use
/dev/urandom, but that's only available on Linux.
from
/usr/portage/net-misc/tightvnc/files/tightvnc-1.3_alpha7-gentoo.security.patch:
PID and part of the encrypted form of the password.  Ideally we'd use
/dev/urandom, but that's only available on Linux.

-Gentoo BaseLayout from /usr/portage/sys-fs/cryptsetup/files/cryptfs.confd:
If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom

-Ssp security patch in the hardened profile silently falls back to urandom if
erandom is not there, it doesn't die refusing to use an unsafe randomness:
     * Attempt to open kernel pseudo random device if one exists before
     * opening urandom to avoid system entropy depletion.

And there are more. Even "safe" rng-tools which you suggest as the best
solution fall back to urandom if no hardware random generator is there
(and they are NOT there unless you know how to and do customize your kernel),
because the mantainer listened users and understood the issue:
BUG http://bugs.gentoo.org/show_bug.cgi?id=47107
and from /usr/portage/sys-apps/rng-tools/files/rngd:
start-stop-daemon --start --quiet --exec /usr/sbin/rngd -- -b -r /dev/urandom

Then there's "the majority" who prefer the approach you took...
grep urandom /usr/portage/profiles/use.*
/usr/portage/profiles/use.local.desc:dev-libs/apr:urandom - Use /dev/urandom
instead of /dev/random
/usr/portage/profiles/use.local.desc:dev-libs/cyrus-sasl:urandom - Use
/dev/urandom instead of /dev/random
... that is you and cyrus-sasl

so, tell me that you like this way, ignore my rant, whatever but don't even try
to make it look the way every gentoo dev would or should take.

> problem that can be worked around in much better ways then using /dev/urandom.
> There are entropy deamons out there that help /dev/random fill - that is the
> solutions most users should use.
> 
and yet ewarning about this fine solution is way too much work, i know.

Federico

*** Bug 142089 has been marked as a duplicate of this bug. ***

In reply to comment #18
After becomming the latest victim to this silent breakage, I concur with
Federico Galassi sentiment that it is asinine to make /dev/random the default
w/o at least a warning from the apr ebuild

Still really annoying and takes time to found first what's going wrong and then
hitting this bug :(

*** Bug 188195 has been marked as a duplicate of this bug. ***