Peter Samuelson wrote:
> The problem is that svnserve is often used in 'inetd' mode, one
> connection per process. I've recommended that for years, as being
> easier and less hassle than managing a separate daemon. Given inetd
> mode, your approach will exhaust /dev/random just as fast as the status
> quo.
True. Well, to avoid exhausting /dev/random, one needs some fallback
source for the nonce. There are two cases:
- in 'inetd' mode, I guess the pid could work.
- in non-inetd mode, an in-process PRNG would work well.
Using the timestamp as nonce feels a little silly, given that the
challenge is going to look like
<nonce.timestamp@hostname>
Though it's better than just using nonce=0, say (since some
hard-to-predict amount of time passes between when the nonce and
timestamp are generated for the challenge). Times like these make me
wish that more systems had erandom or some other interface for
lower-quality random numbers.
The random(4) manpage says:
If you are unsure about whether you should use /dev/random or
/dev/urandom, then probably you want to use the latter. As a
general rule, /dev/urandom should be used for everything
except long-lived GPG/SSL/SSH keys.
APR was fixed accordingly in version 1.3.3 (see r652830,
"configure.in: Prefer /dev/urandom over /dev/random"). Running
$ strings /usr/lib/libapr-1.so.0.4.5 | grep dev
/dev/zero
/dev/urandom
/dev/null
I see that Debian has the fix.
If refining the Debian-specific code here, please consider patching
the upstream code for the !APR_HAS_RANDOM case, too. That way, your
changes can get a wider audience and more review, it is more likely
that the code will be updated when assumptions of the surrounding code
change, and people on those rare platforms that lack a secure random
number source would benefit as well.
Sorry to have been taking so long to figure this one out.
