Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Wed, Jun 2, 2010 at 4:23 PM, Joe Orton jor...@redhat.com wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) +1. -- justin
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 02.06.2010 18:23, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) Regards, Joe +1 Regards Rüdiger
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 6/1/2010 6:37 PM, Igor Galić wrote: * Solaris 10: 0.9.7 with backports... don't recall what's in the Coolstack but someone else may be able to tell us. The Coolstack and the Webstack both use the system's SSL bindings. Coolstack symlinks it: libssl.so.0.9.7 = /usr/sfw/lib/libssl.so.0.9.7 lrwxrwxrwx 1 root root 28 Jul 13 2009 /opt/coolstack/lib/libssl.so.0.9.7 - /usr/sfw/lib/libssl.so.0.9.7 while webstack links it directly: libcrypto.so.0.9.7 = /usr/sfw/lib/libcrypto.so.0.9.7 Bye, Didn't coolstack officially die? It's been replaced by glassfish IIRC... As such, it's not a good example
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 31 May 2010, at 22:10, Sander Temme wrote: I think this goes hand in hand with what operating system versions we will be targeting for 2.4. We should inventory which versions of the libraries are offered on each and then make the decision whether to accomodate: I don't think that's our concern. The downstream distros are moving targets just as much as we are, and they'll each make their own decision on when to bundle our new releases. Upgrading a dependency is hardly going to be a showstopper! It seems that 0.9.8 is still fairly prevalent, and dropping support for it in 2.3/2.4 might hurt adoption in the near term. That is, prevalent based on decisions made some time ago, probably in many cases at the time they first moved from 2.0 to 2.2. -- Nick Kew
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) Regards, Joe
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Jun 2, 2010, at 12:23 PM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) How about --with-ssl only looks for OpenSSL = 1.0.0 and we have a new option, --with-old-ssl (or whatever) which allows for 0.9.[87] varieties...
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Jun 2, 2010, at 9:23 AM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL +1 across the board. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Jun 2, 2010, at 9:30 AM, Jim Jagielski wrote: On Jun 2, 2010, at 12:23 PM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) How about --with-ssl only looks for OpenSSL = 1.0.0 and we have a new option, --with-old-ssl (or whatever) which allows for 0.9.[87] varieties... Would it reduce the complexity of the autofoo behind it enough to justify the increase in complexity for the user^Wbuilder? S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Jun 2, 2010, at 12:33 PM, Sander Temme wrote: On Jun 2, 2010, at 9:30 AM, Jim Jagielski wrote: On Jun 2, 2010, at 12:23 PM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) How about --with-ssl only looks for OpenSSL = 1.0.0 and we have a new option, --with-old-ssl (or whatever) which allows for 0.9.[87] varieties... Would it reduce the complexity of the autofoo behind it enough to justify the increase in complexity for the user^Wbuilder? Well, the idea is that anyone building an SSL 2.4 using the same options as for 2.2 will get OpenSSL 1.0.0 only and by default. If they don't have it, it forces them to take action and either install 1.0.0 or change their build process to use the deprecation option.
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 5/25/2010 7:45 AM, Joe Orton wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. +1 to axing all SSLC related conditionals, RSA clearly doesn't care that this was once supported, so neither should we. +1 to axing all OpenSSL 0.9.7 and prior versions, which are no longer supported by the openssl team. -1 to axing OpenSSL 0.9.8, which remains supported by the openssl team.
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Wed, Jun 2, 2010 at 12:23 PM, Joe Orton jor...@redhat.com wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) +1
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 02.06.2010 18:23, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL= 0.9.8 - support and build with OpenSSL= 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) +1, don't know enough about other SSL libraries, so neutral concerning that point. Rainer
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 6/2/2010 11:23 AM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop The reason I'm not keen on this is that 0.9.7 is missing security fixes and will never receive another refresh. So it's certainly not recommended anymore for 2.0 or 2.2, nevermind 'the next' release. I don't think we need to go out of our way to break it, but if there are tests for 0.9.7'ness (or 0.9.8-initial) we won't need those tests anymore.
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Wed, Jun 02, 2010 at 01:18:17PM -0500, William Rowe wrote: On 6/2/2010 11:23 AM, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop The reason I'm not keen on this is that 0.9.7 is missing security fixes and will never receive another refresh. So it's certainly not recommended anymore for 2.0 or 2.2, nevermind 'the next' release. I'm with you on this, but comments in this thread about wanting to keep support for RHEL4 and Solaris 10 native (patched) 0.9.7* are not unreasonable. I don't think we need to go out of our way to break it, but if there are tests for 0.9.7'ness (or 0.9.8-initial) we won't need those tests anymore. Right, yup, that's basically what I propose. Regards, Joe
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
Deprecating obsolete libraries is a good thing, especially if there is a compelling replacement. I think this goes hand in hand with what operating system versions we will be targeting for 2.4. We should inventory which versions of the libraries are offered on each and then make the decision whether to accomodate: * Windows: none * Mac OS X 10.6: OpenSSL 0.9.8l 5 Nov 2009 * FreeBSD 6.4-STABLE: OpenSSL 0.9.7e-p1 25 Oct 2004 * FreeBSD 7.2-STABLE: OpenSSL 0.9.8e 23 Feb 2007 * FreeBSD 8-STABLE: OpenSSL 0.9.8k 25 Mar 2009 * OpenBSD 4.6: OpenSSL 0.9.8k 25 Mar 2009 * Solaris 10: 0.9.7 with backports... don't recall what's in the Coolstack but someone else may be able to tell us. The Coolstack and the Webstack both use the system's SSL bindings. Coolstack symlinks it: libssl.so.0.9.7 = /usr/sfw/lib/libssl.so.0.9.7 lrwxrwxrwx 1 root root 28 Jul 13 2009 /opt/coolstack/lib/libssl.so.0.9.7 - /usr/sfw/lib/libssl.so.0.9.7 while webstack links it directly: libcrypto.so.0.9.7 = /usr/sfw/lib/libcrypto.so.0.9.7 Bye, -- Igor Galić Tel: +43 (0) 699 122 96 338 Fax: +43(0) 1 91 333 41 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
Re: drop support for OpenSSL 1.0 in trunk/2.3?
On 25.05.2010 15:09, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Joe Orton Sent: Dienstag, 25. Mai 2010 14:46 To: dev@httpd.apache.org Subject: RFC: drop support for OpenSSL 1.0 in trunk/2.3? I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) While the pros sound promising this is a real strong con. Especially as this would mean that 2.4 would not work with OpenSSL 1.0. The problem I see is that if you want to use other OS provided libraries like openldap they have dependencies on the OS provided OpenSSL and binding Apache against a different OpenSSL version as these libraries are bound against looks like a big problem if Apache is bound to them as well. And building a whole stack of dependencies for Apache seems to be a too large hurdle for me for adoption. So currently I would be -1 (vote not veto) on this. The same for me. Supporting only 0.9.8 and newer seems to be OK w.r.t. to supported platforms and what they provide now or what can be expected from them. Deciding about a minimum 0.9.8 patch version is harder. Although it would be good if vendors would support secure reneg soon, I doubt that most users will have it on their servers in the next few years. Some might get a backport into the vendor supplied version, but not really a full 0.9.8n or higher. So I'd be +1 for dropping support for OpenSSL 0.9.8. Regards, Rainer
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On May 29, 2010, at 6:02 AM, Steve Marquess wrote: Dr Stephen Henson wrote: On 25/05/2010 13:45, Joe Orton wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt I have several times requested access to sslc from RSA, for the stated purpose of testing Apache integration, and have always been summarily denied. Can it. So... love/hate? Deprecating obsolete libraries is a good thing, especially if there is a compelling replacement. I think this goes hand in hand with what operating system versions we will be targeting for 2.4. We should inventory which versions of the libraries are offered on each and then make the decision whether to accomodate: * Windows: none * Mac OS X 10.6: OpenSSL 0.9.8l 5 Nov 2009 * FreeBSD 6.4-STABLE: OpenSSL 0.9.7e-p1 25 Oct 2004 * FreeBSD 7.2-STABLE: OpenSSL 0.9.8e 23 Feb 2007 * FreeBSD 8-STABLE: OpenSSL 0.9.8k 25 Mar 2009 * OpenBSD 4.6: OpenSSL 0.9.8k 25 Mar 2009 * Solaris 10: 0.9.7 with backports... don't recall what's in the Coolstack but someone else may be able to tell us. * Sunfreeware.com: 1.0.0 and 0.9.7g, with both Apache 2.0.59 and 2.2.15 built against 1.0.0 * Red Hat 5: 0.9.8b with backports * Red Hat 4: 0.9.7 with backports * Ubuntu 10.04: OpenSSL 0.9.8k 25 Mar 2009 ... It seems that 0.9.8 is still fairly prevalent, and dropping support for it in 2.3/2.4 might hurt adoption in the near term. con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not supported in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 module with 0.9.8 if possible). Belated comment: FIPS 140-2 is used with Apache, both directly as open source and as vendor supplied binaries. FIPS 140-2 is required in U.S. DoD and federal government environments (where I do much of my consulting work). That requirement has been in place for years but is now actually being enforced. Many users would like to upgrade but can't due to that requirement. Until a new FIPS validation is available for OpenSSL 1.0.0 it would IMHO be a Very Bad Thing to drop support for 0.9.8. Such a validation will require commercial or government sponsorship, as did the earlier validations, plus a long lead time. We get occasional expressions of interest but nothing solid yet, but I'm confident it will happen eventually. In the meantime, dropping support for 0.9.8 will force many government sector Apache users elsewhere. Please note that no released version of Apache knows how to put OpenSSL into FIPS mode. When your Many Users run Apache in a situation with FIPS requirements, which and whose patches do they use? Work on FIPS integration at Apache itself stalled in 2007: http://svn.apache.org/viewvc/httpd/sandbox/gaithersburg/README-FIPS?view=log and the last commit message: In an effort to dissuade users from adopting this tree as 'ready for openssl fips', rename this repository. Gaithersburg happens to be one of the two campuses of NIST who issues the FIPS standards. When this is ready to be merged to httpd and apr, it's ready. Not before, there is a security policy document for openssl's implementation which must be adhered to. Using FIPS 140-2 certified hardware to protect the RSA private keys for websites generally happens mostly transparently through OpenSSL Engines, of which I can tell you that one, CHIL, works perfectly fine in 1.0.0. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 31/05/2010 22:10, Sander Temme wrote: Please note that no released version of Apache knows how to put OpenSSL into FIPS mode. When your Many Users run Apache in a situation with FIPS requirements, which and whose patches do they use? Work on FIPS integration at Apache itself stalled in 2007: http://svn.apache.org/viewvc/httpd/sandbox/gaithersburg/README-FIPS?view=log That comment refers to the older 1.1 module which was has been superseded by the 1.2 validation. I submitted a patch for the 1.2 module and support is now in trunk and a backport proposed to 2.2.x, see the SSLFIPS directive. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
Dr Stephen Henson wrote: On 25/05/2010 13:45, Joe Orton wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt So... love/hate? con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not supported in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 module with 0.9.8 if possible). Belated comment: FIPS 140-2 is used with Apache, both directly as open source and as vendor supplied binaries. FIPS 140-2 is required in U.S. DoD and federal government environments (where I do much of my consulting work). That requirement has been in place for years but is now actually being enforced. Many users would like to upgrade but can't due to that requirement. Until a new FIPS validation is available for OpenSSL 1.0.0 it would IMHO be a Very Bad Thing to drop support for 0.9.8. Such a validation will require commercial or government sponsorship, as did the earlier validations, plus a long lead time. We get occasional expressions of interest but nothing solid yet, but I'm confident it will happen eventually. In the meantime, dropping support for 0.9.8 will force many government sector Apache users elsewhere. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Tue, May 25, 2010 at 6:14 AM, Jeff Trawick traw...@gmail.com wrote: There's no ready answer to this, but I wonder: How much of the current conditional logic is required to support the OpenSSL in fully patched RHEL 4 fully patched Solaris 10 (some other typical server platform that bundles OpenSSL) Please add Mac OS X to this list. Making mod_ssl in trunk not work on Mac OS X is very yucky, IMO. -- justin
RFC: drop support for OpenSSL 1.0 in trunk/2.3?
I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt So... love/hate? Regards, Joe
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 25/05/2010 13:45, Joe Orton wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt So... love/hate? con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not supported in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 module with 0.9.8 if possible). If you'd said 0.9.8m (because 0.9.8m and later support reneg extension) I'd be very much in favour. I haven't checked but are there many remaining toolkit issues with supporting 0.9.8m and later? The CRL revocation checking in 0.9.8 is more primitive than 1.0.0 but still should be better than the broken manual stuff mod_ssl uses. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
RE: drop support for OpenSSL 1.0 in trunk/2.3?
-Original Message- From: Joe Orton Sent: Dienstag, 25. Mai 2010 14:46 To: dev@httpd.apache.org Subject: RFC: drop support for OpenSSL 1.0 in trunk/2.3? I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) While the pros sound promising this is a real strong con. Especially as this would mean that 2.4 would not work with OpenSSL 1.0. The problem I see is that if you want to use other OS provided libraries like openldap they have dependencies on the OS provided OpenSSL and binding Apache against a different OpenSSL version as these libraries are bound against looks like a big problem if Apache is bound to them as well. And building a whole stack of dependencies for Apache seems to be a too large hurdle for me for adoption. So currently I would be -1 (vote not veto) on this. Regards Rüdiger
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Tue, May 25, 2010 at 8:45 AM, Joe Orton jor...@redhat.com wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's sure pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg OTOH, I guess that if our encouragement is successful then there would be fewer httpd installations utilizing mostly-painless OpenSSL patches from their OS vendor over the next few years. That may be bad for security overall. con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) bad for 2.3 alpha/beta testing con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt don't care So... love/hate? both --/-- There's no ready answer to this, but I wonder: How much of the current conditional logic is required to support the OpenSSL in fully patched RHEL 4 fully patched Solaris 10 (some other typical server platform that bundles OpenSSL)
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Tue, May 25, 2010 at 9:03 AM, Dr Stephen Henson shen...@oss-institute.org wrote: On 25/05/2010 13:45, Joe Orton wrote: con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not supported in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 module with 0.9.8 if possible). Does that FIPS 140-2 mean much to Apache, for very long, without TLS 1.2 built on top of it? Would such a thing (TLS 1.2 on top of a validated SHA2) be more likely to ever bshow up in 0.9.8 or 1.0.0? -- Eric Covener cove...@gmail.com
Re: drop support for OpenSSL 1.0 in trunk/2.3?
On Tuesday 25 May 2010, Plüm, Rüdiger, VF-Group wrote: While the pros sound promising this is a real strong con. Especially as this would mean that 2.4 would not work with OpenSSL 1.0. The problem I see is that if you want to use other OS provided libraries like openldap they have dependencies on the OS provided OpenSSL and binding Apache against a different OpenSSL version as these libraries are bound against looks like a big problem if Apache is bound to them as well. And building a whole stack of dependencies for Apache seems to be a too large hurdle for me for adoption. So currently I would be -1 (vote not veto) on this. I agree with Rüdiger, there are too many systems with older openssl around and upgrading only openssl is problematic. Would it make any sense to drop support for openssl 0.9.8, or maybe 0.9.8m? Would that still lead to a significant simplification of the code?
