Ben Laurie <[EMAIL PROTECTED]> writes: > Karl Fogel wrote: > > Branko Äibej <[EMAIL PROTECTED]> writes: > > > >>>Or gstein has suggested that apr_generate_random_bytes() can grow a > >>>new flag, indicating urandom is preferred. > >> > >>That would look weird to APR users on systems that have never heard of > >>/dev/random and /dev/urandom (several come to mind, all of which use \ > >>for the path separator). > > Yeah. Anyway, the question of random vs unrandom is an > > implementation > > detail, it doesn't belong in interface. The *real* problem here is > > the blocking behavior -- which is visible to callers and is > > appropriate to address in the interface, maybe like this: > > Woah! That's so wrong! The problem is that if you really want n bits > of _real_ randomness, you may _have_ to block. > > The most general fix I can think of is an interface where you pass > _three_ numbers. k, n and i, where k is the number of bits of > randomness you want, n is the number of bits of entropy you want for > _this_ chunk of randomness, and i is the number of initial bits of > entropy you want invested in randomness.
I have to admit, Ben, I don't know enough math to understand your proposal, or how to implement it. And I don't understand how this UI proposal directly addresses the issue of blocking vs. non-blocking. In my ideal world, apr's ./configure would locate both /dev/random and /dev/urandom. Then we add a simple boolean flag: either block and give quality random data, or never block, with the risk of returning poor quality data. Let the Caller Beware. If folks don't want to add a flag, we can just create a new function: apr_generate_random_bytes_nonblocking() or somesuch. Subversion really needs this. Repository creation of FreeBSD 4.X potentially blocks forever at the moment, and people are being burned. If I submitted a patch for this, would anyone object? I'd rather get a "pretty good" solution into APR right now, rather wait for someone to implement a complex API.
