Re: Poll: increase OpenSSL version requirement for trunk?

[Stefan Eissing]

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?

[Houser, Rick]

> 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?

[Bernard Spil]

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?

[Eric Covener]

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?

[Eric Covener]

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?

[Stefan Eissing]

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?

[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?

[Jim Jagielski]

> 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?

[Ruediger Pluem]

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?

[Noel Butler]

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?

[Nick Kew]

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?

[William A Rowe Jr]

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?

[Jan Ehrhardt]

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?

[Eric Covener]

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?

[Rainer Jung]

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?

[Eric Covener]

> 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?

[Eric Covener]

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]

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?

[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.

Re: Poll: increase OpenSSL version requirement for trunk?

[Rainer Jung]

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?

[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.

Poll: increase OpenSSL version requirement for trunk?

[Rainer Jung]

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