Re: Poll: increase OpenSSL version requirement for trunk?
I understand what you are saying and agree to most of it. One thing sticks out to me: > Am 19.03.2018 um 19:07 schrieb Houser, Rick : > > Under RHEL6, I count 52 releases of openssl-1.0.1# in the changelog. That > is far from trivial, especially compared to httpd/apr/apr-util that seem to > only *need* around 1-2 updates rounds per year to deal with security issues, > etc. The OpenSSL project has not made that many releases of 1.0.1+. So where do the 52 package versions come from? I imagine they isolated and backported patches separately which appeared in a single openssl release? If so: from a global, net wide perspective this is completely nuts! Complexity is our worst enemy. By multiplying releases by a factor 5-10 of a common, shared software, the OS distributor makes everyones life more difficult. Apply that to all the libs on the common OS and you end up with a big number, because they multiply each other. Now, one can argue that the OS distributor is testing all this and therefore it is safe. Maybe that is true. But if you install a piece of software that is not part of your OS distribution tests, that software encounters versions of shared libraries it has never seen before. I remember my horror when I realized that my installed Apache httpd 2.4.n was a Frankenstein monster created by my distribution. How naive I was then... Back down to earth: I understand how we got here, but I still do not like it. Cheers, Stefan *rambling*
RE: Poll: increase OpenSSL version requirement for trunk?
> I may be an odd-ball that I want to manage this kind of a setup but I > think that if you can build one application, you can build more. They > happily live separated into /usr/local on RHEL7... Can, does not necessarily imply should. From an end-user perspective, the less work I need to do for the desired outcome, the better. For each and every application I compile, I take responsibility for all related maintenance. If I just link against the distro versions of libraries, I don't incur an ongoing cost beyond applying standard distro patches. If I build an openssl library from source, I also need to stay on top of all security related patches to that library that a distro would typically manage for me. Under RHEL6, I count 52 releases of openssl-1.0.1# in the changelog. That is far from trivial, especially compared to httpd/apr/apr-util that seem to only *need* around 1-2 updates rounds per year to deal with security issues, etc. In this case, since you are already maintaining an OpenSSL port and keeping that current, I assume this sunk cost basically looks free to you from the httpd perspective? If so, I would agree that there's little benefit to NOT using your latest openssl package version in the same repo/tree, as that's going to be available to your users and similarly supported. However, the latest distro supported version available for a large number of servers is a patched 1.0.1e (RHEL6, which ships with httpd 2.2.15). Rick Houser Web Engineer > -Original Message- > From: Bernard Spil [mailto:br...@freebsd.org] > Sent: Monday, March 19, 2018 13:23 > To: dev@httpd.apache.org > Subject: Re: Poll: increase OpenSSL version requirement for trunk? > > EXTERNAL EMAIL > > > Naturally, there was something I saw in the archives I want to react > upon, even if not a vote... > I am also the maintainer of the OpenSSL (and LibreSSL) ports for > FreeBSD and am the author of many patches for LibreSSL, No-SSLv2, > No-SSLv3 for upstream projects. > > I was searching for the rationale to provide a version of Apache which > is newer than what you get from your Operating System. > > Obviously, there _is_ a need to have something newer than your OS, > e.g. Apache 2.4.6 on RHEL 7 is missing too many features. > When you are smart enough to be able to build your own Apache httpd, > are you not also smart enough to build all dependencies? > FWIW: I manage, to my dismay, 2 Apache front-end servers acting as > reverse proxy on RHEL7. When I ran into update problems with the > Base-OS I decided that I would just build the whole stack (from zlib > upwards) from the ground up. > If you would want mod_http2 you are in trouble on these old systems in > all cases, curl with HTTP/2 support? libnghttp2 in your repos? > > Managing multiple versions of OpenSSL is already a head-ache. For 1.1 > you need compat shims or lots of ifdefs, 1.1.1 (currently -pre2) will > only add to that... > > I may be an odd-ball that I want to manage this kind of a setup but I > think that if you can build one application, you can build more. They > happily live separated into /usr/local on RHEL7... > > Cheers, Bernard.
Re: Poll: increase OpenSSL version requirement for trunk?
Naturally, there was something I saw in the archives I want to react upon, even if not a vote... I am also the maintainer of the OpenSSL (and LibreSSL) ports for FreeBSD and am the author of many patches for LibreSSL, No-SSLv2, No-SSLv3 for upstream projects. I was searching for the rationale to provide a version of Apache which is newer than what you get from your Operating System. Obviously, there _is_ a need to have something newer than your OS, e.g. Apache 2.4.6 on RHEL 7 is missing too many features. When you are smart enough to be able to build your own Apache httpd, are you not also smart enough to build all dependencies? FWIW: I manage, to my dismay, 2 Apache front-end servers acting as reverse proxy on RHEL7. When I ran into update problems with the Base-OS I decided that I would just build the whole stack (from zlib upwards) from the ground up. If you would want mod_http2 you are in trouble on these old systems in all cases, curl with HTTP/2 support? libnghttp2 in your repos? Managing multiple versions of OpenSSL is already a head-ache. For 1.1 you need compat shims or lots of ifdefs, 1.1.1 (currently -pre2) will only add to that... I may be an odd-ball that I want to manage this kind of a setup but I think that if you can build one application, you can build more. They happily live separated into /usr/local on RHEL7... Cheers, Bernard.
Re: Poll: increase OpenSSL version requirement for trunk?
On Mon, Mar 19, 2018 at 9:06 AM, Stefan Eissing wrote: > It seems we converge against keeping 2.4.x requirements and base line > as is, but want a modern one for trunk. > > But unless that is released in a 2.6.x it won't mean a thing. Especially > when people want to keep the old code in for portability of fixes to 2.4. > > Can't have it both ways, I think. Did I miss something? I agree there is little value in a trunk-only requirement bump if there is never a subsequent release. But without knowing what the future holds, I think drawing a line in the sand now while it's on our minds is still pretty reasonable, and probably makes the next bump easier depending on when a later release comes together. I don't see why the old code would be (necessarily) problematic to retain though. If it is, then I'd be looking at the long-term outlook for 2.4 to see which is the lesser f two evils. (my 2c not at full face value -- I have little stake in mod_ssl/openssl)
Re: Poll: increase OpenSSL version requirement for trunk?
On Mon, Mar 19, 2018 at 8:57 AM, Yann Ylavic wrote: > On Mon, Mar 19, 2018 at 1:07 PM, Jim Jagielski wrote: >> >> >>> On Mar 17, 2018, at 3:32 PM, Nick Kew wrote: >>> >>> On Fri, 16 Mar 2018 09:06:53 -0400 >>> Eric Covener wrote: >>> I think bump trunk now, but not rip out any compat code for ease of backport. >>> >>> +1. >>> >>> 2.4 is a stable branch: we can't go making changes that would >>> disrupt existing users. >>> >>> What we could do is make it an annoying (even scary) Warning >>> in 2.4, and see what reactions that brings. >>> >> >> +1 from me > > ISTR that we had a several complains about a warning introduced in > (the middle of) 2.4, possibly SSLCertificateChainFile's deprecation > message at each startup? > It was not quite accepted by the community and we reverted it later > (the release was rejected IIRC). > I wouldn't want the same thing to happen again. One noteworthy difference in this case is that it could affect just builders / maintainers directly. > People running 2.4 with a deprecated version of openssl are probably > well aware about it, and likely can't do much at this point. > Unless/until one can selectively drop an AH by (simple) configuration... The other options essentially punish everyone else. We maintain another release and they feel compelled to move to it, or we jump through hoops to maintain compat (more complexity, time that could be spent elsewhere) -- Eric Covener cove...@gmail.com
Re: Poll: increase OpenSSL version requirement for trunk?
It seems we converge against keeping 2.4.x requirements and base line as is, but want a modern one for trunk. But unless that is released in a 2.6.x it won't mean a thing. Especially when people want to keep the old code in for portability of fixes to 2.4. Can't have it both ways, I think. Did I miss something? -Stefan > Am 19.03.2018 um 13:57 schrieb Yann Ylavic : > > On Mon, Mar 19, 2018 at 1:07 PM, Jim Jagielski wrote: >> >> >>> On Mar 17, 2018, at 3:32 PM, Nick Kew wrote: >>> >>> On Fri, 16 Mar 2018 09:06:53 -0400 >>> Eric Covener wrote: >>> I think bump trunk now, but not rip out any compat code for ease of backport. >>> >>> +1. >>> >>> 2.4 is a stable branch: we can't go making changes that would >>> disrupt existing users. >>> >>> What we could do is make it an annoying (even scary) Warning >>> in 2.4, and see what reactions that brings. >>> >> >> +1 from me > > ISTR that we had a several complains about a warning introduced in > (the middle of) 2.4, possibly SSLCertificateChainFile's deprecation > message at each startup? > It was not quite accepted by the community and we reverted it later > (the release was rejected IIRC). > I wouldn't want the same thing to happen again. > > People running 2.4 with a deprecated version of openssl are probably > well aware about it, and likely can't do much at this point. > Unless/until one can selectively drop an AH by (simple) configuration...
Re: Poll: increase OpenSSL version requirement for trunk?
On Mon, Mar 19, 2018 at 1:07 PM, Jim Jagielski wrote: > > >> On Mar 17, 2018, at 3:32 PM, Nick Kew wrote: >> >> On Fri, 16 Mar 2018 09:06:53 -0400 >> Eric Covener wrote: >> >>> I think bump trunk now, but not rip out any compat code for ease of >>> backport. >> >> +1. >> >> 2.4 is a stable branch: we can't go making changes that would >> disrupt existing users. >> >> What we could do is make it an annoying (even scary) Warning >> in 2.4, and see what reactions that brings. >> > > +1 from me ISTR that we had a several complains about a warning introduced in (the middle of) 2.4, possibly SSLCertificateChainFile's deprecation message at each startup? It was not quite accepted by the community and we reverted it later (the release was rejected IIRC). I wouldn't want the same thing to happen again. People running 2.4 with a deprecated version of openssl are probably well aware about it, and likely can't do much at this point. Unless/until one can selectively drop an AH by (simple) configuration...
Re: Poll: increase OpenSSL version requirement for trunk?
> On Mar 17, 2018, at 3:32 PM, Nick Kew wrote: > > On Fri, 16 Mar 2018 09:06:53 -0400 > Eric Covener wrote: > >> I think bump trunk now, but not rip out any compat code for ease of >> backport. > > +1. > > 2.4 is a stable branch: we can't go making changes that would > disrupt existing users. > > What we could do is make it an annoying (even scary) Warning > in 2.4, and see what reactions that brings. > +1 from me
Re: Poll: increase OpenSSL version requirement for trunk?
On 03/16/2018 02:06 PM, Eric Covener wrote: > On Fri, Mar 16, 2018 at 8:50 AM, Rainer Jung wrote: >> Am 16.03.2018 um 13:20 schrieb Eric Covener: >>> >>> On Fri, Mar 16, 2018 at 8:07 AM, Rainer Jung >>> wrote: Last time we had the discussion was 2010/2011. We might increase minimum OpenSSL version for everything newer than 2.4.x to OpenSSL 1.0.1. I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least without service pack). I do not know about BSD and others. Of course increasing the minimum requirement to 1.0.1 makes backports a bit more risky. On the other hand I think our support promise for old OpenSSL is probably no longer true, because likely almost nobody will test anything newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement might hold for 2.4.x, but there we are bound due to our support for older platforms. Do we have more data points? Opinions about increasing to 1.0.1? >>> >>> >>> I prefer to see it bumped in 2.4 with 1-2 year window. >> >> >> ... and wait with a dependency bump for 2.6+ also 1-2 years? Or do it there >> earlier? > > I think bump trunk now, but not rip out any compat code for ease of backport. > +1 Regards Rüdiger
Re: Poll: increase OpenSSL version requirement for trunk?
On 18/03/2018 05:32, Nick Kew wrote: > On Fri, 16 Mar 2018 09:06:53 -0400 > Eric Covener wrote: > >> I think bump trunk now, but not rip out any compat code for ease of >> backport. > > +1. > > 2.4 is a stable branch: we can't go making changes that would > disrupt existing users. +1 agreed, bump it to >= 1.0.2 for trunk/2.6, but don't mess with 2.4, I'm sure that will backfire in spectacular ways (A colleague reading this over my shoulder, just said " fastest way for me to stop updating apache" my comment was, what a bout critical bug finds, his reply "fasted way for me to move to nginx ") > What we could do is make it an annoying (even scary) Warning > in 2.4, and see what reactions that brings. Why? most software with "major" version releases have minimum requirements, openssl will just be one of them for httpd, no need to terrorise innocent sys admins just for your jollies :) -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: Poll: increase OpenSSL version requirement for trunk?
On Fri, 16 Mar 2018 09:06:53 -0400 Eric Covener wrote: > I think bump trunk now, but not rip out any compat code for ease of > backport. +1. 2.4 is a stable branch: we can't go making changes that would disrupt existing users. What we could do is make it an annoying (even scary) Warning in 2.4, and see what reactions that brings. -- Nick Kew
Re: Poll: increase OpenSSL version requirement for trunk?
For trunk/next only I support Yann's thoughts here. Within the ecosystem, do we actually worry about pairing 1.0.0 OpenSSL, pcre 6.x etc with 2.6.0 httpd? Is there any expectation that running SLES 11 will let you build modern packages? Or RHEL 5.x ... while in "extended" pseduo-support, RedHat offers nothing more than critical fixes, and won't target new software to run on that platform. I suggest it isn't our issue to keep a new release running on such thing. All these dependencies also build on such old platforms, and while it will be rare for a user to wish to run a modern httpd on a more ancient distro, it obviously can be done. My distro component rev tracking table is here, just enabled comments for suggested edits; https://docs.google.com/spreadsheets/d/1y5tENm_L8m0tV5iJHPfg9pQoBTeyjCB8JxwkNEwuH44/edit?usp=sharing Realistically, we should never change our prerequisites on a released version major.minor, so 2.4 is set in stone. Even with APR we had long ago agreed to support 1.5.x for the lifespan, although some new modules or features would not be supported with that older flavor. But with any httpd version.next, if it is already part of the modern vendor distribution ecosystem, let's move on. By the time vendors adopt, we are time-shifted into relevance. On Mar 16, 2018 07:44, "Eric Covener" wrote: On Fri, Mar 16, 2018 at 8:36 AM, Yann Ylavic wrote: > On Fri, Mar 16, 2018 at 1:34 PM, Yann Ylavic wrote: >> As already said on the other thread... >> >> On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: >>> >>> Do we have more data points? Opinions about increasing to 1.0.1? >> >> +1, and while at it I think I think we should even require 1.0.2 (if >> possible) since 1.0.1 in no longer supported at OpenSSL. > > Per: https://www.openssl.org/policies/releasestrat.html Although I personally have no need with $bigco hat on (no openssl/mod_ssl here) I would not want to go too far and make life overly difficult for maintainers who are several years into some long/complicated support lifecycle. Not that I know 1.0.2 is somehow problematic or anything.
Re: Poll: increase OpenSSL version requirement for trunk?
Yann Ylavic in gmane.comp.apache.devel (Fri, 16 Mar 2018 13:34:55 +0100): >As already said on the other thread... > >On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: >> >> Do we have more data points? Opinions about increasing to 1.0.1? > >+1, and while at it I think I think we should even require 1.0.2 (if >possible) since 1.0.1 in no longer supported at OpenSSL. Do not forget that 1.0.1 still is the standard on distros like CentOS 6 (with backported security patches). # openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 -- Jan
Re: Poll: increase OpenSSL version requirement for trunk?
On Fri, Mar 16, 2018 at 8:50 AM, Rainer Jung wrote: > Am 16.03.2018 um 13:20 schrieb Eric Covener: >> >> On Fri, Mar 16, 2018 at 8:07 AM, Rainer Jung >> wrote: >>> >>> Last time we had the discussion was 2010/2011. >>> >>> We might increase minimum OpenSSL version for everything newer than 2.4.x >>> to >>> OpenSSL 1.0.1. >>> >>> I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an >>> alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least >>> without >>> service pack). I do not know about BSD and others. >>> >>> Of course increasing the minimum requirement to 1.0.1 makes backports a >>> bit >>> more risky. On the other hand I think our support promise for old OpenSSL >>> is >>> probably no longer true, because likely almost nobody will test anything >>> newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement >>> might hold for 2.4.x, but there we are bound due to our support for older >>> platforms. >>> >>> Do we have more data points? Opinions about increasing to 1.0.1? >> >> >> I prefer to see it bumped in 2.4 with 1-2 year window. > > > ... and wait with a dependency bump for 2.6+ also 1-2 years? Or do it there > earlier? I think bump trunk now, but not rip out any compat code for ease of backport.
Re: Poll: increase OpenSSL version requirement for trunk?
Am 16.03.2018 um 13:20 schrieb Eric Covener: On Fri, Mar 16, 2018 at 8:07 AM, Rainer Jung wrote: Last time we had the discussion was 2010/2011. We might increase minimum OpenSSL version for everything newer than 2.4.x to OpenSSL 1.0.1. I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least without service pack). I do not know about BSD and others. Of course increasing the minimum requirement to 1.0.1 makes backports a bit more risky. On the other hand I think our support promise for old OpenSSL is probably no longer true, because likely almost nobody will test anything newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement might hold for 2.4.x, but there we are bound due to our support for older platforms. Do we have more data points? Opinions about increasing to 1.0.1? I prefer to see it bumped in 2.4 with 1-2 year window. ... and wait with a dependency bump for 2.6+ also 1-2 years? Or do it there earlier? Am 16.03.2018 um 13:34 schrieb Yann Ylavic: > As already said on the other thread... > > On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: >> >> Do we have more data points? Opinions about increasing to 1.0.1? > > +1, and while at it I think I think we should even require 1.0.2 (if > possible) since 1.0.1 in no longer supported at OpenSSL. > Per: https://www.openssl.org/policies/releasestrat.html Am 16.03.2018 um 13:44 schrieb Eric Covener: > Although I personally have no need with $bigco hat on (no > openssl/mod_ssl here) I would not want to go too far and make life > overly difficult for maintainers who are several years into some > long/complicated support lifecycle. Not that I know 1.0.2 is somehow > problematic or anything. It seems that RHEL supports 1.0.2 starting with 7.4. I did not find any 1.0.2 info for SLES 12, it seems they are still at 1.0.1. So I would slightly prefer increasing to 1.0.1 for trunk soon and I would be OK with doing the same as suggested by Eric after announcement in a 1-2 years time frame for 2.4.x. Regards, Rainer
Re: Poll: increase OpenSSL version requirement for trunk?
> I found this page > > https://www.suse.com/documentation/suse-best-practices/singlehtml/securitymodule/securitymodule.html > > which mentions >>the “SUSE Linux Enterprise 11 Security Module”, providing > enhancements to SUSE Linux Enterprise 11 SP3, and later SP4.<< > > The packages are in a special repository named > "nu_novell_com:SLE11-Security-Module", details on that page. I have not > tried it though. Sorry, I see that you had already implied it as an alternative in the initial post -- I missed that detail.
Re: Poll: increase OpenSSL version requirement for trunk?
On Fri, Mar 16, 2018 at 8:36 AM, Yann Ylavic wrote: > On Fri, Mar 16, 2018 at 1:34 PM, Yann Ylavic wrote: >> As already said on the other thread... >> >> On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: >>> >>> Do we have more data points? Opinions about increasing to 1.0.1? >> >> +1, and while at it I think I think we should even require 1.0.2 (if >> possible) since 1.0.1 in no longer supported at OpenSSL. > > Per: https://www.openssl.org/policies/releasestrat.html Although I personally have no need with $bigco hat on (no openssl/mod_ssl here) I would not want to go too far and make life overly difficult for maintainers who are several years into some long/complicated support lifecycle. Not that I know 1.0.2 is somehow problematic or anything.
Re: Poll: increase OpenSSL version requirement for trunk?
On Fri, Mar 16, 2018 at 1:34 PM, Yann Ylavic wrote: > As already said on the other thread... > > On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: >> >> Do we have more data points? Opinions about increasing to 1.0.1? > > +1, and while at it I think I think we should even require 1.0.2 (if > possible) since 1.0.1 in no longer supported at OpenSSL. Per: https://www.openssl.org/policies/releasestrat.html
Re: Poll: increase OpenSSL version requirement for trunk?
As already said on the other thread... On Fri, Mar 16, 2018 at 1:07 PM, Rainer Jung wrote: > > Do we have more data points? Opinions about increasing to 1.0.1? +1, and while at it I think I think we should even require 1.0.2 (if possible) since 1.0.1 in no longer supported at OpenSSL.
Re: Poll: increase OpenSSL version requirement for trunk?
Am 16.03.2018 um 13:20 schrieb Eric Covener: On Fri, Mar 16, 2018 at 8:07 AM, Rainer Jung wrote: Last time we had the discussion was 2010/2011. We might increase minimum OpenSSL version for everything newer than 2.4.x to OpenSSL 1.0.1. I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least without service pack). I do not know about BSD and others. Of course increasing the minimum requirement to 1.0.1 makes backports a bit more risky. On the other hand I think our support promise for old OpenSSL is probably no longer true, because likely almost nobody will test anything newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement might hold for 2.4.x, but there we are bound due to our support for older platforms. Do we have more data points? Opinions about increasing to 1.0.1? I prefer to see it bumped in 2.4 with 1-2 year window. My unmaintained SLES 11.0 is at 9.8h but I know from other contexts that 11.0 is very unique/unusable/unsupportable. But I poked around an update repo and could not find a 1.x anywhere. I am a bit surprised. But I don't think this should hold us or users back. I found this page https://www.suse.com/documentation/suse-best-practices/singlehtml/securitymodule/securitymodule.html which mentions >>the “SUSE Linux Enterprise 11 Security Module”, providing enhancements to SUSE Linux Enterprise 11 SP3, and later SP4.<< The packages are in a special repository named "nu_novell_com:SLE11-Security-Module", details on that page. I have not tried it though. Regards, Rainer
Re: Poll: increase OpenSSL version requirement for trunk?
On Fri, Mar 16, 2018 at 8:07 AM, Rainer Jung wrote: > Last time we had the discussion was 2010/2011. > > We might increase minimum OpenSSL version for everything newer than 2.4.x to > OpenSSL 1.0.1. > > I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an > alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least without > service pack). I do not know about BSD and others. > > Of course increasing the minimum requirement to 1.0.1 makes backports a bit > more risky. On the other hand I think our support promise for old OpenSSL is > probably no longer true, because likely almost nobody will test anything > newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement > might hold for 2.4.x, but there we are bound due to our support for older > platforms. > > Do we have more data points? Opinions about increasing to 1.0.1? I prefer to see it bumped in 2.4 with 1-2 year window. My unmaintained SLES 11.0 is at 9.8h but I know from other contexts that 11.0 is very unique/unusable/unsupportable. But I poked around an update repo and could not find a 1.x anywhere. I am a bit surprised. But I don't think this should hold us or users back.
Poll: increase OpenSSL version requirement for trunk?
Last time we had the discussion was 2010/2011. We might increase minimum OpenSSL version for everything newer than 2.4.x to OpenSSL 1.0.1. I think RHEL 6 and SLES11 both provide OpenSSL 1.0.1 at least as an alternative. RHEL 7 and SLES 12 still seems to be at 1.0.1 (at least without service pack). I do not know about BSD and others. Of course increasing the minimum requirement to 1.0.1 makes backports a bit more risky. On the other hand I think our support promise for old OpenSSL is probably no longer true, because likely almost nobody will test anything newer than 2.4.x with OpenSSL 0.9.8, 0.9.9 or 1.0.0. The same statement might hold for 2.4.x, but there we are bound due to our support for older platforms. Do we have more data points? Opinions about increasing to 1.0.1? Regards, Rainer