Hi, In December, 2004, Alex Jacques reported[1]:
> 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: > > http://svnbook.red-bean.com/en/1.1/apb.html#svn-ap-b-sect-1.2.14 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? [1] http://bugs.debian.org/285708
