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 attachment 66784 [details, diff] 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 attachment 66877 [details, diff] 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. ***
