Re: Looking ahead to 2.4.13 / 2.2.30

[Jim Jagielski <ji...@jaguNET.com>]

Yeah... I was gonna propose that once I had the weekend
to take a more in-depth look at 2.4... But I am +1 for
a release v. soon.

Yeah, I'll RM 2.4
> On Apr 30, 2015, at 5:52 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On Tue, 31 Mar 2015 10:49:47 -0400
> Jim Jagielski <ji...@jaguNET.com> wrote:
> 
> > BTW: Would it make sense to consider a release of 2.4.13 in April
> > to coincide w/ ApacheCon?
> 
> We've historically produced a release at the beginning of the con.
> It worked really well when we would hackathon two days, then retire
> to do other con stuff for the balance of the event with a new
> release in the hopper looking for votes.
> 
> I'd love to see us tag and roll releases based on our efforts
> throughout the entire gathering, sometime in that following week.
> I offer to T&R an update of 2.2 as well to pick up any issues we
> resolve over the course of that week.
> 
> It seems that we have 2 groups of good things to come out of ApacheCon,
> some immediate fixes for things like BSD project efforts, some pretty
> straightforward defects that have been resolved... and then there's a bunch
> of energy about enhancements and the h2 universe.
> 
> In the short term, WDYT about giving the trees a week to settle, grab the
> low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
> week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to T&R 2.2.30 
> in tandem.
> 
> Concerns / observations / thoughts?
> 
> Bill

Re: Looking ahead to 2.4.13 / 2.2.30

[Michael Felt <ma...@gmail.com>]

I never assume it is easy. As far as AIX goes, it would be "easier" for me,
as a packager to ignore AIX 5.3. But, for now, what I package for AIX 5.3
(TL7 and later) also works on AIX 6.1 and AIX 7.1 - unchanged.

Getting people to update is hard. Some do it automatically - proud to be
bleading edge, some never update regardless of argument.

I would hope that by changing any requisites (e.g., minimal level of
openssl) would not change the behavior of the application. If it does, then
I would tend to follow (what I think you are saying) - that such a change
is not permitted. In that case, hurrying a new release where it is
applicable (e.g., 2.6.X) might be sensible - if a factor such as security
is the driving (emotional) motivator.

What was I thinking? Well, little me was considering the recent "media"
storms re: web-related security (when they mean the servers that browsers
connect to) - and what an organization (perhaps community is a better word)
could do to assist from the server side - rather than placing ALL the
responsibility and load on the remote device (phone, tablet, desktop).

So, yes - it it "breaks" the server by raising the bar as far as XXX is
concerned, we cannot, or maybe should not, raise that bar for those
releases with an "improved" XXX.

As far as OpenSSL goes - maybe the only affected component is mod_ssl. I am
probably completely offbase (I like simple worldviews when I can get away
with it) - but I thought OpenSSL is an API. I would hope the API for 0.9.7
and 0.9.8 are compatible; while openssl-1.0.0 and OpenSSL-0.9.X are not.
And again, that is only an issue if something in the new API is definitely
needed. If not, something like mod_ssl might still link against
OpenSSL-0.9.8 - but, as far as ASF httpd and mod_ssl is concerned -
security concerns with the root cause in openssl-0.9.8 are not supported.

Please excuse my rambling: too many phone calls in between.

In short, if it does not impact the expected behavior of httpd I would hope
that dropping "support" for openssl-0.9.X will improve "the product" and be
a motivator for upgrading, rather than a limiting factor. (Oh how I love my
pink glasses :) )

On Fri, May 8, 2015 at 2:29 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> FWIW...
>
> On Fri, May 8, 2015 at 2:16 AM, Michael Felt <ma...@gmail.com> wrote:
>
>> From my perspective - as a simple packager (re: openssl - old versions) I
>> run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12)
>>
>
> So, an operating system that has been unsupported for the past 2 years,
> check...
>
>
>> In short, there are ways around dependencies on old versions of openssl
>> on AIX. And further, if a 'user' is not willing to upgrade their OpenSSL -
>> why would you think they are going to upgrade to the latest httpd-2.2.x (or
>> any version for that matter).
>>
>
> Indeed, most won't, hopefully they are busy deploying a supported OS still
> receiving security updates, check...
>
> The rules change - and we (read "me and other users") cannot reasonably
>> claim "latest and greatest from ASF" while requiring support for insecure
>> openssl.
>>
>
> And the latest and greatest is 2.4.{last}, not 2.2.{bump} legacy update,
> and nobody would assume otherwise, check...
>
>
>> IMHO - you, ASF, also have an implied responsibility to the users of
>> Apache httpd powered sites. Being backward compatible too long keeps
>> weaknesses alive.
>>
>
> Therefore we ensure everyone who would otherwise pick up security fixes in
> the future will refuse to do so, because we stubbornly force a
> breaking/incompatible behavior change on some subversion legacy
> maintainence bump?  And yourself, a packager, shipping new packages for an
> operating system with vulnerabilities which are no longer being patched?
>  check...
>
> I've proposed changing the *default* config, universally, across all
> shipping versions.  Yann proposes to enhance mod_ssl in non-breaking ways
> even back to 2.2, because 75-80% of the deployed servers have yet to update
> to 2.4.  Not that most won't eventually, but right now, they are at 2.2.
>
> About users who have deployed a server, you can rant about employing the
> cudgel to the foolish administrators' skulls who won't re-configure their
> systems, however that is not an effective tool to ensure users update to
> the least-buggy, least-insecure subversion release of the software.  It was
> mentioned in another thread, but just as an example, ripping out SSLv3
> essentially means that every user with older back-end services will *never*
> update again, period.  Is that a rational act by an upstream project?
>
> When discussing 2.2 and 2.4, altering the behavior of an update is not in
> scope.  Upgrades are a multi-layered project which require other systems to
> be rolled out first, in waves.  In the case of back end applications, you
> have a redevelopment cycle where you are adapting to the latest
> Java/Python/PHP/whatever before the back end service can be updated to a
> hosting framework which supports TLSv1.2 properly.
>
> Altering the behavior of the next upgrade, 2.5.0-dev (trunk) is absolutely
> in scope, and knowing it will be quite a while before that sees a General
> Availability release, it makes the most sense to be forward-looking and
> anticipate the state of TLS that much further down the road.  That can
> include ripping out SSLv3 and TLSv1.0.
>
>
>
>

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr <wr...@rowe-clan.net>]

FWIW...

On Fri, May 8, 2015 at 2:16 AM, Michael Felt <ma...@gmail.com> wrote:

> From my perspective - as a simple packager (re: openssl - old versions) I
> run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12)
>

So, an operating system that has been unsupported for the past 2 years,
check...


> In short, there are ways around dependencies on old versions of openssl on
> AIX. And further, if a 'user' is not willing to upgrade their OpenSSL - why
> would you think they are going to upgrade to the latest httpd-2.2.x (or any
> version for that matter).
>

Indeed, most won't, hopefully they are busy deploying a supported OS still
receiving security updates, check...

The rules change - and we (read "me and other users") cannot reasonably
> claim "latest and greatest from ASF" while requiring support for insecure
> openssl.
>

And the latest and greatest is 2.4.{last}, not 2.2.{bump} legacy update,
and nobody would assume otherwise, check...


> IMHO - you, ASF, also have an implied responsibility to the users of
> Apache httpd powered sites. Being backward compatible too long keeps
> weaknesses alive.
>

Therefore we ensure everyone who would otherwise pick up security fixes in
the future will refuse to do so, because we stubbornly force a
breaking/incompatible behavior change on some subversion legacy
maintainence bump?  And yourself, a packager, shipping new packages for an
operating system with vulnerabilities which are no longer being patched?
 check...

I've proposed changing the *default* config, universally, across all
shipping versions.  Yann proposes to enhance mod_ssl in non-breaking ways
even back to 2.2, because 75-80% of the deployed servers have yet to update
to 2.4.  Not that most won't eventually, but right now, they are at 2.2.

About users who have deployed a server, you can rant about employing the
cudgel to the foolish administrators' skulls who won't re-configure their
systems, however that is not an effective tool to ensure users update to
the least-buggy, least-insecure subversion release of the software.  It was
mentioned in another thread, but just as an example, ripping out SSLv3
essentially means that every user with older back-end services will *never*
update again, period.  Is that a rational act by an upstream project?

When discussing 2.2 and 2.4, altering the behavior of an update is not in
scope.  Upgrades are a multi-layered project which require other systems to
be rolled out first, in waves.  In the case of back end applications, you
have a redevelopment cycle where you are adapting to the latest
Java/Python/PHP/whatever before the back end service can be updated to a
hosting framework which supports TLSv1.2 properly.

Altering the behavior of the next upgrade, 2.5.0-dev (trunk) is absolutely
in scope, and knowing it will be quite a while before that sees a General
Availability release, it makes the most sense to be forward-looking and
anticipate the state of TLS that much further down the road.  That can
include ripping out SSLv3 and TLSv1.0.

Re: Looking ahead to 2.4.13 / 2.2.30

[Michael Felt <ma...@gmail.com>]

>From my perspective - as a simple packager (re: openssl - old versions) I
run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12).
With AIX 6.1 and 7.1 it would be openssl-1.0.0(something - do not know by
memory what patchlevel IBM openssl.base is at). Personally, I am going to
look at packaging against LibreSSL. There are only three #ifdefs I needed
to add to get it to build. My apologies for being so late with saying
anything about this (I have been busy with 'regular' work.

I will start a new thread later today - and do it again from trunks of
2.2.x, 2.4.x and 2.5.x.

In short, there are ways around dependencies on old versions of openssl on
AIX. And further, if a 'user' is not willing to upgrade their OpenSSL - why
would you think they are going to upgrade to the latest httpd-2.2.x (or any
version for that matter).

The rules change - and we (read "me and other users") cannot reasonably
claim "latest and greatest from ASF" while requiring support for insecure
openssl. IMHO - you, ASF, also have an implied responsibility to the users
of Apache httpd powered sites. Being backward compatible too long keeps
weaknesses alive.

Michael

p.s. - for what is is worth +1 to drop 0.9.7 (maybe even 0.9.8 - but must
test more)

Michael

On Thu, May 7, 2015 at 11:50 PM, Yann Ylavic <yl...@gmail.com> wrote:

> +1
>
> On Thu, May 7, 2015 at 6:45 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > Looking at the proposals in RFC 7525, I'm thinking this is a good time to
> > re-sync
> > httpd to these guidelines, even if it defers these releases by a week.
> > WDYT?
> >
> > Bill
> >
> > On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >>
> >> Yeah... I was gonna propose that once I had the weekend
> >> to take a more in-depth look at 2.4... But I am +1 for
> >> a release v. soon.
> >>
> >> Yeah, I'll RM 2.4
> >> > On Apr 30, 2015, at 5:52 PM, William A Rowe Jr <wr...@rowe-clan.net>
> >> > wrote:
> >> >
> >> > On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr.
> >> > <wr...@rowe-clan.net> wrote:
> >> > On Tue, 31 Mar 2015 10:49:47 -0400
> >> > Jim Jagielski <ji...@jaguNET.com> wrote:
> >> >
> >> > > BTW: Would it make sense to consider a release of 2.4.13 in April
> >> > > to coincide w/ ApacheCon?
> >> >
> >> > We've historically produced a release at the beginning of the con.
> >> > It worked really well when we would hackathon two days, then retire
> >> > to do other con stuff for the balance of the event with a new
> >> > release in the hopper looking for votes.
> >> >
> >> > I'd love to see us tag and roll releases based on our efforts
> >> > throughout the entire gathering, sometime in that following week.
> >> > I offer to T&R an update of 2.2 as well to pick up any issues we
> >> > resolve over the course of that week.
> >> >
> >> > It seems that we have 2 groups of good things to come out of
> ApacheCon,
> >> > some immediate fixes for things like BSD project efforts, some pretty
> >> > straightforward defects that have been resolved... and then there's a
> >> > bunch
> >> > of energy about enhancements and the h2 universe.
> >> >
> >> > In the short term, WDYT about giving the trees a week to settle, grab
> >> > the
> >> > low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
> >> > coming
> >> > week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to T&R
> 2.2.30
> >> > in tandem.
> >> >
> >> > Concerns / observations / thoughts?
> >> >
> >> > Bill
> >>
> >
>

Re: Looking ahead to 2.4.13 / 2.2.30

[Yann Ylavic <yl...@gmail.com>]

+1

On Thu, May 7, 2015 at 6:45 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Looking at the proposals in RFC 7525, I'm thinking this is a good time to
> re-sync
> httpd to these guidelines, even if it defers these releases by a week.
> WDYT?
>
> Bill
>
> On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> Yeah... I was gonna propose that once I had the weekend
>> to take a more in-depth look at 2.4... But I am +1 for
>> a release v. soon.
>>
>> Yeah, I'll RM 2.4
>> > On Apr 30, 2015, at 5:52 PM, William A Rowe Jr <wr...@rowe-clan.net>
>> > wrote:
>> >
>> > On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr.
>> > <wr...@rowe-clan.net> wrote:
>> > On Tue, 31 Mar 2015 10:49:47 -0400
>> > Jim Jagielski <ji...@jaguNET.com> wrote:
>> >
>> > > BTW: Would it make sense to consider a release of 2.4.13 in April
>> > > to coincide w/ ApacheCon?
>> >
>> > We've historically produced a release at the beginning of the con.
>> > It worked really well when we would hackathon two days, then retire
>> > to do other con stuff for the balance of the event with a new
>> > release in the hopper looking for votes.
>> >
>> > I'd love to see us tag and roll releases based on our efforts
>> > throughout the entire gathering, sometime in that following week.
>> > I offer to T&R an update of 2.2 as well to pick up any issues we
>> > resolve over the course of that week.
>> >
>> > It seems that we have 2 groups of good things to come out of ApacheCon,
>> > some immediate fixes for things like BSD project efforts, some pretty
>> > straightforward defects that have been resolved... and then there's a
>> > bunch
>> > of energy about enhancements and the h2 universe.
>> >
>> > In the short term, WDYT about giving the trees a week to settle, grab
>> > the
>> > low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
>> > coming
>> > week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to T&R 2.2.30
>> > in tandem.
>> >
>> > Concerns / observations / thoughts?
>> >
>> > Bill
>>
>

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr <wr...@rowe-clan.net>]

Looking at the proposals in RFC 7525, I'm thinking this is a good time to
re-sync
httpd to these guidelines, even if it defers these releases by a week.
WDYT?

Bill

On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski <ji...@jagunet.com> wrote:

> Yeah... I was gonna propose that once I had the weekend
> to take a more in-depth look at 2.4... But I am +1 for
> a release v. soon.
>
> Yeah, I'll RM 2.4
> > On Apr 30, 2015, at 5:52 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. <wr...@rowe-clan.net>
> wrote:
> > On Tue, 31 Mar 2015 10:49:47 -0400
> > Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > > BTW: Would it make sense to consider a release of 2.4.13 in April
> > > to coincide w/ ApacheCon?
> >
> > We've historically produced a release at the beginning of the con.
> > It worked really well when we would hackathon two days, then retire
> > to do other con stuff for the balance of the event with a new
> > release in the hopper looking for votes.
> >
> > I'd love to see us tag and roll releases based on our efforts
> > throughout the entire gathering, sometime in that following week.
> > I offer to T&R an update of 2.2 as well to pick up any issues we
> > resolve over the course of that week.
> >
> > It seems that we have 2 groups of good things to come out of ApacheCon,
> > some immediate fixes for things like BSD project efforts, some pretty
> > straightforward defects that have been resolved... and then there's a
> bunch
> > of energy about enhancements and the h2 universe.
> >
> > In the short term, WDYT about giving the trees a week to settle, grab the
> > low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
> coming
> > week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to T&R 2.2.30
> > in tandem.
> >
> > Concerns / observations / thoughts?
> >
> > Bill
>
>