David Reid wrote: > A while back there was a comment on this list that the ssl code should > be "ripped out" before the next release. There was no additional > information as to why, but that's OK.
Actually, I don't know that it is OK. 1.2.9 on the current-stable branch should be released shortly. Independent of the 1.3 changes for SSL. Does SSL block any other change in 1.3? > Maybe it should be removed into a seperate module along the same lines > as apr-iconv? Additionally we should look at what really needs to go > into it. There are a few bits of code that I'd like to think about > moving into a library with apr's platform independance, but the bloat > that is apr-util no longer seems like the ideal landing site. In fairness, the bloat which is apr-util is agreeably just-bloat. Don't worry about it, there is a much greater urgency to remove 4 of 6 db libs which an application won't consume, or ldap for a non-ldap application. And ssl, if ssl is not used by an application. It's a bigger problem than the openssl bindings. > So, thoughts? Comments? Suggestions? > > FWIW, this will have ramifications for some other code that I plan on > working on soon(ish). A big comment. APR and APR-util current include non-FIPS implementations of FIPS-140 specified algorithms. OpenSSL built with FIPS enabled has proper implementations. So please don't begin yanking openssl. In fact I need to toggle off those apr-implementations, and stub in openssl's implementations in the presence of some --enable-fips flag. Apache+APR+OpenSSL won't 'become FIPS certified' (in fact, only a small core of OpenSSL is fips validated). But as things stand, it violates the FIPS standard and security policy document. I hope to change that. So we can all agree that apr-util is bloated, but please leave things as-is for 1.3?
