apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: PR #44881
Date Thu, 01 May 2008 23:05:40 GMT
Bojan Smojver wrote:
> On Mon, 2008-04-28 at 17:33 -0500, William A. Rowe, Jr. wrote:
> 
>> Interesting thought, keep in mind the other half of the issue is the number
>> of times we consume generate_random_bytes ourselves from other functions,
>> you'll have to suggest which should be pseudo, which should be truly random
>> and which should be configurable.
> 
> Bill, are we doing something about this before 1.3.0 gets out?

As it turns out only UUID code is affected (on platforms which have no
native uuid generation function).  Note that predicting the next UUID is
a serious flaw when they are used as session identifiers, etc, and that the
native implementations all switched to strong crypto once this potential
flaw was identified.

So no, I would not change the manner that UUID's are generated to urandom.
generate_random_bytes is defined to provide the greatest entropy we can
obtain.  It is not, after all, generate_psuedorandom_bytes.

I think the _ex() flavor offering two alternatives plus blocking is a very
exciting new feature, but given that this only came up in the past week, and
that people have been waiting much longer for 1.3.0's new features, I just
don't see the reason to hold this up any longer.

If we want a shorter window to 1.4.0, we have to stop dragging out revision
bumps this long, eh?  Which means to move forward with 1.3.0 now and perhaps
we'll be no further than 1.3.3 when we are ready with the ssl, evp, and our
other substantial 1.4.0 enhancements.

Bill


Mime
View raw message