httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Felt <>
Subject Re: Looking ahead to 2.4.13 / 2.2.30
Date Fri, 08 May 2015 14:04:46 GMT
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 <>

> FWIW...
> On Fri, May 8, 2015 at 2:16 AM, Michael Felt <> 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.

View raw message