Re: [PATCH] get mod_ssl to work again

[Jeff Trawick <tr...@attglobal.net>]

Justin Erenkrantz <je...@ebuilt.com> writes:

> I think that truerand isn't installed in enough places that it 
> merits our redistribution in APR.  -- justin

+1 in general...  AIX, OS/390, Tru64, HP-UX, older Solaris are
platforms I play on that don't have /dev/*random (leaving
mod_auth_digest unsupported)

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.

truerand is supposedly pretty slow anyway.  Perhaps we can make it
enen slower such by making it do its magic in a separate process to
avoid any interference with the signalling already in place?

Maybe the first time apr_generate_random_bytes() is called we
create a separate process where the truerand stuff runs and we talk to
it through a pipe?  That is sort of like the entropy-gathering daemons
folks are using already except that it is handled under the covers by
APR.  Or until somebody screams have it fork, do its magic, and exit
to avoid process cleanup problems?

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: Internal PRNG was Re: [PATCH] get mod_ssl to work again

[Jeff Trawick <tr...@attglobal.net>]

Justin Erenkrantz <je...@ebuilt.com> 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 | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Internal PRNG was Re: [PATCH] get mod_ssl to work again

[Justin Erenkrantz <je...@ebuilt.com>]

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?

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?

I know that Knuth Vol. 2 has a bunch of stuff on PRNGs in concept.
I don't know how current that is.  Numerical Recipies in C has a
chapter on randomness (Chapter 7).

http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookc.html

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