AW: Simplify download distribution directory by dropping sha1 hashes?

2017-10-23 Thread Plüm , Rüdiger , Vodafone Group 
Sounds reasonable to me.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Montag, 23. Oktober 2017 20:37
> An: httpd 
> Betreff: Simplify download distribution directory by dropping sha1
> hashes?
> 
> HTTPD team,
> 
> Since our downloads are to be authenticated by their .asc PGP
> signatures, and the hashes simply serve as checksums, is it reasonable
> to offer only MD5 and SHA256 at this point?
> 
> Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
> supported checksum. All others should apply the strongest hash
> validation.
> 
> Thoughts?
> 
> Bill

Re: Simplify download distribution directory by dropping sha1 hashes?

2017-10-23 Thread Daniel Ruggeri 
+1
-- 
Daniel Ruggeri


 Original Message 
From: William A Rowe Jr 
Sent: October 23, 2017 1:36:31 PM CDT
To: httpd 
Subject: Simplify download distribution directory by dropping sha1 hashes?

HTTPD team,

Since our downloads are to be authenticated by their .asc PGP
signatures, and the hashes simply serve as checksums, is it reasonable
to offer only MD5 and SHA256 at this point?

Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
supported checksum. All others should apply the strongest hash
validation.

Thoughts?

Bill

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

2017-10-23 Thread William A Rowe Jr 
Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  wrote:
> The issue obviously isn't in the *tagging*. It is the unknown
> aspect of what is expected AFTER the tagging.
>
> I see the tagging as simply a mechanism to force action
> upon the PMC to go down a route which the PMC has not
> decided, from what I can tell, to go down. Maybe I'm wrong.
> But your reply tends to support that interpretation. The tag, per
> se, is not the goal. The goal is to "push" 2.5.0 when, again
> from what I can tell, the PMC has not decided that such
> a push is warranted/needed/desired/whatever.
>
> So if you want to tag, first generate a roadmap, that can be
> shared and discussed with the PMC, and the dev community,
> what that 1st step is intended to lead us to. But let's
> not pretend that such tagging is simply noting a SVN revision.
>
> You may complain that I "single handedly" do Foo and Bar
> and other dictatorial and dangerous stuff, but AFAIK, I've
> never done or proposed anything w/o bringing it up
> to the list 1st (ala PROXY support, mod_wsgi, health
> checks... etc...). Even w/ releases and tags I give
> people more than 24hours notice. Unless, of course,
> your tag was under Lazy Consensus, in which case my
> "veto" was valid, if more "strong" than required. In
> which case, I am sorry for that.

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

2017-10-23 Thread Jim Jagielski 
The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which case, I am sorry for that.

Simplify download distribution directory by dropping sha1 hashes?

2017-10-23 Thread William A Rowe Jr 
HTTPD team,

Since our downloads are to be authenticated by their .asc PGP
signatures, and the hashes simply serve as checksums, is it reasonable
to offer only MD5 and SHA256 at this point?

Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
supported checksum. All others should apply the strongest hash
validation.

Thoughts?

Bill

Re: [users@httpd] [ANNOUNCE] Apache HTTP Server 2.4.29 Released

2017-10-23 Thread William A Rowe Jr 
On Mon, Oct 23, 2017 at 11:53 AM, William A Rowe Jr  wrote:
> On Mon, Oct 23, 2017 at 11:45 AM, Jim Jagielski  wrote:
>>  Apache HTTP Server 2.4.29 Released
>>
>> October 23, 2017
>>
>> The Apache Software Foundation and the Apache HTTP Server Project
>> are pleased to announce the release of version 2.4.29 of the Apache
>> HTTP Server ("Apache").  This version of Apache is our latest GA
>> release of the new generation 2.4.x branch of Apache HTTPD and
>> represents fifteen years of innovation by the project, and is
>> recommended over all previous releases. This release of Apache is
>> a security, feature, and bug fix release.
>>
>> We consider this release to be the best version of Apache available, and
>> encourage users of all prior versions to upgrade.
>>
>> Apache HTTP Server 2.4.29 is available for download from:
>>
>>   http://httpd.apache.org/download.cgi
>
> Broken link.

And... back in sync. Thanks for RM'ing!

Re: [users@httpd] [ANNOUNCE] Apache HTTP Server 2.4.29 Released

2017-10-23 Thread William A Rowe Jr 
On Mon, Oct 23, 2017 at 11:45 AM, Jim Jagielski  wrote:
>  Apache HTTP Server 2.4.29 Released
>
> October 23, 2017
>
> The Apache Software Foundation and the Apache HTTP Server Project
> are pleased to announce the release of version 2.4.29 of the Apache
> HTTP Server ("Apache").  This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> recommended over all previous releases. This release of Apache is
> a security, feature, and bug fix release.
>
> We consider this release to be the best version of Apache available, and
> encourage users of all prior versions to upgrade.
>
> Apache HTTP Server 2.4.29 is available for download from:
>
>   http://httpd.apache.org/download.cgi

Broken link.

[ANNOUNCE] Apache HTTP Server 2.4.29 Released

2017-10-23 Thread Jim Jagielski 
 Apache HTTP Server 2.4.29 Released

October 23, 2017

The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.29 of the Apache
HTTP Server ("Apache").  This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
recommended over all previous releases. This release of Apache is
a security, feature, and bug fix release.

We consider this release to be the best version of Apache available, and
encourage users of all prior versions to upgrade.

Apache HTTP Server 2.4.29 is available for download from:

  http://httpd.apache.org/download.cgi

Apache 2.4 offers numerous enhancements, improvements, and performance
boosts over the 2.2 codebase.  For an overview of new features
introduced since 2.4 please see:

  http://httpd.apache.org/docs/trunk/new_features_2_4.html

Please see the CHANGES_2.4 file, linked from the download page, for a
full list of changes. A condensed list, CHANGES_2.4.29 includes only
those changes introduced since the prior 2.4 release.  A summary of all 
of the security vulnerabilities addressed in this and earlier releases 
is available:

  http://httpd.apache.org/security/vulnerabilities_24.html

This release requires the Apache Portable Runtime (APR), minimum
version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may
require the 1.6.x version of both APR and APR-Util. The APR libraries
must be upgraded for all features of httpd to operate correctly.

This release builds on and extends the Apache 2.2 API.  Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.4, and require minimal or no source code changes.

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

When upgrading or installing this version of Apache, please bear in mind
that if you intend to use Apache with one of the threaded MPMs (other
than the Prefork MPM), you must ensure that any modules you will be
using (and the libraries they depend on) are thread-safe.

Please note that while the Apache HTTP Server Project may publish some
security patches to the 2.2.x flavor through at least December of 2017,
no further maintenance patches of 2.2.x will be considered and no further
releases will be distributed. The 2.2.x branch has now reached the end of
its maintenance, and users are strongly encouraged to promptly complete
their transitions to this 2.4.x flavor of httpd to benefit from security
and bug fixes, as well as new features.

Re: SSLProxy* in section

2017-10-23 Thread William A Rowe Jr 
On Mon, Oct 23, 2017 at 9:54 AM, Stefan Eissing
 wrote:
>
>> Am 23.10.2017 um 16:25 schrieb Yann Ylavic :
>>
>> Hi Stefan,
>>
>> On Mon, Oct 23, 2017 at 2:42 PM, Stefan Eissing
>>  wrote:
>>>
>>> Can you give me a sign if this will arrive soonish or need to be stashed? 
>>> Thanks!
>>
>> I've just updated the backport proposal with the change (r1812193)
>> intended to address compatibility issues raised by Bill (MMN major
>> bump). Looks good to me, Bill?
>>
>> Appart from this, it's still missing votes (2 now since I had to reset
>> Mike's with the change), so reviewers/testers welcome ;)
>
> Quid pro quo. Fair enough. ;-)
>
> I'll await Bill's verdict and review if his thumb is up.

I will review whether ABI is satisfied later this week, don't let that
stop other reviewers from pounding on this change.

I still propose a "State of the /trunk" release candidate this week,
eyeing only an -alpha release to the public, so that all of the
aspects of trunk which now vary from 2.4.x maintenance branch can be
thoroughly inspected by those users who are willing to do so.

So any feature that feels "experimental" or simply untested will
receive some additional eyeballs, and we can start to address any
deficiencies without continuing to disrupt 2.4.x stable in the
process.

I will make this tag later in the week, holler if you see something
you want to and and *will* address over the remainder of this week,
I'm willing to pause 7-10 days to let some things be corrected. I'd
like to make this a monthly exercise, so what is missed can be fixed
for end of Nov. It will be good to have all these enhancements shared
with the community, even if only at -alpha level recognition for a
bit.

Re: SSLProxy* in section

2017-10-23 Thread Stefan Eissing 


> Am 23.10.2017 um 16:25 schrieb Yann Ylavic :
> 
> Hi Stefan,
> 
> On Mon, Oct 23, 2017 at 2:42 PM, Stefan Eissing
>  wrote:
>> 
>> Can you give me a sign if this will arrive soonish or need to be stashed? 
>> Thanks!
> 
> I've just updated the backport proposal with the change (r1812193)
> intended to address compatibility issues raised by Bill (MMN major
> bump). Looks good to me, Bill?
> 
> Appart from this, it's still missing votes (2 now since I had to reset
> Mike's with the change), so reviewers/testers welcome ;)

Quid pro quo. Fair enough. ;-)

I'll await Bill's verdict and review if his thumb is up.

Re: SSLProxy* in section

2017-10-23 Thread Yann Ylavic 
Hi Stefan,

On Mon, Oct 23, 2017 at 2:42 PM, Stefan Eissing
 wrote:
>
> Can you give me a sign if this will arrive soonish or need to be stashed? 
> Thanks!

I've just updated the backport proposal with the change (r1812193)
intended to address compatibility issues raised by Bill (MMN major
bump). Looks good to me, Bill?

Appart from this, it's still missing votes (2 now since I had to reset
Mike's with the change), so reviewers/testers welcome ;)

SSLProxy* in section

2017-10-23 Thread Stefan Eissing 
Guys, what is the status of the 2.4.x backport?

 *) mod_proxy, mod_ssl: Handle SSLProxy* directives in  sections,

I'd like to propose several mod_ssl backports to then propose a mod_md 
backport, but the missing proxy changes makes the merge rather non-automatic, 
it seems. I can do a patch without, but if you then backport, all the time was 
wasted.

Can you give me a sign if this will arrive soonish or need to be stashed? 
Thanks!

-Stefan

AW: mod_rewrite, vary headers and internal redirects

2017-10-23 Thread Plüm , Rüdiger , Vodafone Group 
I would tend to say that the  code is correct and the RewriteCond code is 
wrong, because it doesn’t matter if the condition becomes true or false. The 
headers value has an influence on the result. Tricky question is what to do 
regarding Vary if the non-presence of a header has an influence.

Regards

Rüdiger

Von: Luca Toscano [mailto:toscano.l...@gmail.com]
Gesendet: Sonntag, 22. Oktober 2017 11:47
An: Apache HTTP Server Development List 
Betreff: Re: mod_rewrite, vary headers and internal redirects

Hi everybody,

2017-10-09 13:46 GMT+02:00 Luca Toscano 
>:
Hi Yann,

2017-10-08 14:13 GMT+02:00 Yann Ylavic 
>:
On Sun, Oct 8, 2017 at 2:03 PM, Yann Ylavic 
> wrote:
> Hi Luca,
>
> On Sun, Oct 8, 2017 at 11:59 AM, Luca Toscano 
> > wrote:
>>
>> Does this approach make sense? Is there any smarter way to do it?
>
> I can't tell that I love the hack in internal redirects but looks like
> a simple way to handle the case...
> Nit: maybe a more descriptive name for the "keep-vary-header" note,
> "redirect-keeps-vary"?

+1


But after all, if we reach an internal redirect with some Vary header
already set, maybe we should never drop it, thus internal redirects
should preserve Vary in any case...

I'd prefer to limit the scope of the httpd configurations affected by this 
change to the minimum, but the change would probably look less hacky :)


After https://svn.apache.org/r1811744 trunk should be inline with what the docs 
say, but I have another question now: a RewriteCond condition (containing 
something like HTTP:someheader) adds a Vary header to the response only if the 
condition evaluates to true, meanwhile a  condition adds the Vary header 
regardless. Is there any good motivation for this difference or they should be 
modified to be more consistent? The  block behavior seems to be more sound 
(after reading https://tools.ietf.org/html/rfc7231#section-7.1.4), but I'd like 
to hear more expert opinions :)

Thanks!

Luca