Justin Erenkrantz wrote: > On 1/3/07, Joe Orton <[EMAIL PROTECTED]> wrote: >> Making apr_md5_ctx_t opaque would require bumping the APR-util major >> version either way; if there's enough desire to break API that might as >> well be the way to go?
Well, I simply encapsulated the SHA1 ctx as Justin did, this code's been shipping well over a year. It's the basis for a FIPS-consuming httpd/apr that discarded MD4/MD5 in favor of SHA-1. It's a good short term approach, and necessary for implementors if OpenSSL 1.1 is ever FIPS-revalidated. > We've long talked about merging APR and APR-util into one library for 2.0. Pointers?!? > Perhaps with the new year, we should just swallow it and do it? Now - I thought the public discussion lists were moving twords disolving APR-util into smaller libraries, dependent on specific features that wouldn't swallow the entire world of unnecessary library functionality into every runtime? Forcing every binary that consumes APR to load OpenSSL + OpenLDAP + three to seven different DB/SQL implementations + one to three XML implementations etc ad nausem is completely blink'n insane, as a long term approach. > Take a month or so to clean up any other structures that should be > opaque and drop all deprecated functions? +1 to start some movement twords 2.0 APR[-util]. -1 to the approach offered in the introduction of your proposal :) > Obviously, we'd still support 1.x branch; but new stuff goes into > 2.x... (Ideally, we drop 0.9.x support; which is likely okay as I > don't think httpd intends to do many more httpd 2.0.x releases...) /shrug - I think feature freezing 0.9.x doesn't mean we can't revisit outright bugs that are identified, I just presume they won't show up all that often anymore.
