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: [PATCH] Optimized MD5 implementation from OpenSSL
Date Wed, 03 Jan 2007 17:58:28 GMT
Justin Erenkrantz wrote:
> On 1/3/07, Joe Orton <jorton@redhat.com> 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.


> 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.

View raw message