William A. Rowe, Jr. wrote: > 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?
Not as far as I'm aware. > >> 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. I realise that, but several people have now mentioned other aspects of openssl that they'd like to see supported. Other libs have been mentioned as well. I think all the things that people have mentioned are valid and would be useful additions, but I'm not sure I really want to simply lump them all into apr-util. Having this as a standalone seperate module probably does make more sense in the long term as I can envision having both an apr-ssl and apr-crypto library. Moving these to a seperate repo within apr would seem like the best plan as that way they can be developed on their own timeline, with features coming and going as required for the development process. > >> 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. I don't see how this has direct implications on what happens with the ssl code, but I'm willing for you to correct my misunderstaning :-) > > 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? Given Joe's stance (which I'm taking as a veto) I think removing it and starting a seperate "module" within apr's repo would make the most sense and should remove the veto from 1.3 - making everyone happy. AFAIU we don't need anything special for the move, but the PMC will likely need to have a vote or sacrifice a goat I guess?
