David Reid wrote: > William A. Rowe, Jr. wrote: >> >> Does SSL block any other change in 1.3? > > Not as far as I'm aware.
One I can think of - the threadpool API, but I'm willing to wait for a richer feature set before calling 1.3 baked. I'm pretty sure httpd would like to pick up 1.3.x by the time they are ready to ship httpd-2.4, but that's a little ways off yet and still. >> 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. I really don't want the entire kitchen sink. If we can keep this to the essential nuts and bolts of a TLS conversation, and extracting information about the client and server credentials, then we won't end up with an extension of openssl that CAN'T be supported with cryptocme, gnutls or other equally valid ssl/tls implementations. >> 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. We both need to consume openssl, for different elements. In fact, I'm thinking of refactoring all the pieces that are subject to FIPS-140 explicit implementations (which will just be stubbed out to openssl), and these include every algorithm we have that is part of the openssl project's fips_canister, such as sha1 hashes. >> 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. I definately don't want to see this handled piecemeal. Please leave it in place, and Joe please reconsider your veto. The right way to handle it is to agree to agree on exactly how we will change the ldap/dbm/dbd/xml/xlate/ssl library bindings to be dynamic or modular. Until we agree on that, I DON'T want to special-case ssl :( It's wasted effort. Let's focus on addressing the real issues folks have identified in the apr_ssl_* implementation? Bill
