Philip Martin wrote:
I'm not sure how Linux distributors configure things, but APR itself
defaults to /dev/urandom.
Yup, Bojan corrected me on that too!
I don't think apr_hash_make should be trying to second guess
apr_generate_random_bytes.
I suppose my strong hesitation about handing off to
apr_generate_random_bytes() is that there are ways it can block, and I
think not just with /dev/random but with other non-DEV_RANDOM cases also.
Regardless, apr_hash_make() has never blocked before, so this would be
a change in behaviour even for those who are using apr_generate_random_bytes()
elsewhere in their code. If it's documented, I can see that might be
fine for APR 2.0, or for a new apr_hash_make_random() function in 1.4.
But I'm a little nervous about causing such an apparently simple and
well-known function ("make a new hash") to block when that's never been
its prior behaviour.
This whole topic stems from the problem of an abstraction (a hash
store) which normally works quickly to store and retrieve arbitrary user
input (e.g., CGI arguments) devolving into a slow linked-list operation
given pathological or malicious data. That seems like a classic case
of a "leaky abstraction" to me -- something which usually works like
magic but which can unexpectedly not work well at all.[1]
So, for me at least, addressing that problem by introducing a new
potential leaky abstraction -- an apparently simple call which always
worked quickly before, but which may now block indefinitely on certain
systems -- seems like heading in the wrong direction.
If there are concerns about second-guessing apr_generate_random_bytes(),
I'd personally rather see the use of it dropped entirely in all cases
and the code Bojan worked on as the fallback case always used, since
it adds no significant complexity and appears in line with other solutions,
such as the one in Perl. And if I understand Ben Laurie's note, he was
indicating that truly random entropy (as from /dev/random) is probably
overkill here anyway. Does that make sense?
Chris.
1. http://www.joelonsoftware.com/articles/LeakyAbstractions.html
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
