On 4/14/2011 7:19 PM, Graham Leggett wrote:
>
> Can you explicitly state which design flaws from ap_dbd still exist in apr_crypto, given
> that all the design flaws inherited from apr_dbd were removed in r899910?
Yes, I can, and will, but as mentioned this is a secondary priority to getting apr 1.4,
httpd 2.2.18 and the next httpd 2.3 beta in shape w.r.t. some security concerns, some
win32 review and serious win64 review. Like, last week, but at least wrapping up my
efforts by late tomorrow on apr 1.4.
> I ran a diff from your proposed header against the apr_crypto header on apr-trunk, and
I
> notice that you have reinstated the APU_DECLARE macros, when the apr_trunk code uses
> APR_DECLARE, can you explain why you have done this?
Because I'm editing 1.4.x branch? That's probably my first problem, preparing what
was accomplished already (and compared to what I just re-did in 1.x branch, /sigh)
for backport and adjusted in httpd 2.3 modules, if any of that remains to be done for
GA release. Yes, I've surrendered, and am prepared to ignore whatever apr-unreleased
noise had been emitted by overenthusiastic httpd release processes over my -1, just
to see this completed. Perhaps we call it apr-util 1.5 and declare 1.4 unreleased
(which it was so far), just to disambiguate.
You may be right, and 2.x trunk may be near perfect w.r.t. both crypto and dbd, but
what I read in Jeff's post (and what others expressed interest in recently) is some
release on the 1.x branch. At least unreleased crypto can be made consistent and
transparent for httpd to build against either 1.x or 2.x apr. Would you concur?
My main concern is the relative placement of *this (ctx), **result and *pool in every
functions' arg list, and I have a whole file of the entire 2.x api to review mid-May
at the Wicklow f2f, if it isn't finished prior to that gathering.