Ben's point is more (I think) that if we say we're providing randomness then we should provide that. Bear in mind that APR could be used for a lot of things, and having a potentially very weak random function isn't going to cut it in a lot of places.
FWIW I've seen the sort of api that Ben alludes to elsewhere and don't see a huge problem in using it. That said ben is the math's wunderkind for this stuff so perhaps he can provide an overview of what his proposed api would look like to allay fears. david > 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.
