In December, 2004, Alex Jacques reported:
> If there is little entropy available then svnserve can hang for up to
> several minutes waiting on /dev/random. This is similiar to the problem
> listed here:
As a result, since November, 2005, svnserve on Debian has been patched
to avoid calling apr_generate_random_bytes() and just use the current
time as a nonce. That's ugly. So I'd like your advice.
The random number is used by the CRAM-MD5 auth mechanism in svnserve
(and could be used by other programs calling svn_ra_svn_cram_server
from libsvn_ra_svn-1, though I doubt anyone does that). One
possibility would be to have an internal random number source
initialized from a strong random source at startup, to avoid drawing
on the entropy pool so much. Another possibility would be to enhance
apr's random number source API to allow requesting random bytes
without so much entropy (erandom/frandom) or without blocking on lack
of entropy (urandom).
What do you think? Is forcing !APR_HAS_RANDOM and just using
apr_time_now() as Debian currently does safe, or does it expose users
to a security risk? Would some other simple fix (e.g., calling
"lrand48") make sense and be generally useful?
Received on 2011-11-03 06:45:31 CET