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.
