Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Thu, Dec 20, 2001 at 03:11:54PM -0500, Jeff Trawick wrote:
> > But if you look at how truerand.c actually works, it is questionable
> > that APR should support it as-is because of its use of signals. I
> > don't think APR should be mucking around with signals like that.
>
> Oh, yeah, yuck. Is the use of signal() inherent to its proper
> operation or can we get rid of that?
It looks very integral to me. It seems to rely on the uncertainty of
when the signal will be driven???
> Or, would it make sense to do some research into PRNGs and use
> that as a basis instead of truerand.c? Or, is there some
> worthwhile aspect of truerand.c that merits our use of it?
> Does anyone have any other C implementations (under a suitable
> license) that would be good to use? I'm not sure how good a PRNG
> we need. I'm betting there are some piss-poor /dev/random
> implementations out there anyway. -- justin
All excellent questions :)
While googling around for this sort of thing I've seen complaints
about a /dev/random somebody had for Solaris some time ago.
If we can't find suitable code in the short term, I think for Apache's
benefit we could do some fork+truerand+exit kludge. mod_auth_digest
only needs it during initialization and it is disturbing that
mod_auth_digest won't build on so many platforms (assuming the admin
hasn't gathered truerand themself).
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
