On Tue, Aug 30, 2011 at 08:51:55PM +0200, Stefan Fritsch wrote:
The first regression report, though slightly too late for the vote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825
The byterange_filter.c in the Debian update is exactly the one from
2.2.20. I will keep you updated.
On Aug 31, 2011, at 4:38 AM, Plüm, Rüdiger, VF-Group wrote:
Let's see where we head with the regression report Stefan mentioned.
If it is really something that needs fixing we should go for 2.2.21
and fix the above issues as well.
Agreed… also, if this is such a concern, then Bill should
Apache HTTP Server 2.2.20 Released
The Apache Software Foundation and the Apache HTTP Server Project are
pleased to announce the release of version 2.2.20 of the Apache HTTP
Server (Apache). This version of Apache is principally a security
and bug fix release:
* SECURITY:
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Mittwoch, 31. August 2011 11:13
To: dev@httpd.apache.org
Subject: Re: Regression with range fix
On Tue, Aug 30, 2011 at 08:51:55PM +0200, Stefan Fritsch wrote:
The first regression report, though slightly too
On Aug 31, 2011, at 8:21 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Mittwoch, 31. August 2011 11:13
To: dev@httpd.apache.org
Subject: Re: Regression with range fix
On Tue, Aug 30, 2011 at 08:51:55PM +0200, Stefan
On 8/31/2011 3:41 AM, Plüm, Rüdiger, VF-Group wrote:
It will not fail, as we know that the parameter we pass to apr_bucket_split
is within the limits of apr_size_t due to earlier checks in apr_uint64_t
arithmetic.
It is really just silencing a compiler warning.
Exactly... because this has
On 8/31/2011 5:31 AM, Jim Jagielski wrote:
On Aug 31, 2011, at 4:38 AM, Plüm, Rüdiger, VF-Group wrote:
Let's see where we head with the regression report Stefan mentioned.
If it is really something that needs fixing we should go for 2.2.21
and fix the above issues as well.
Agreed…
Note some additional improvements for a 'final' update 3 advisory...
We aught to mention that mod_header or mod_rewrite and mod_setenvif
are required for their respective workarounds, this apparently confuses
some beginning users.
We aught to mention that backend/application servers are not
On Aug 31, 2011, at 7:20 AM, William A. Rowe Jr. wrote:
We must advise that 1.3 is not affected, per our further research,
although we can note that the default configuration (MaxClients etc)
may already be inappropriate in any number of distributions, and
remind administrators to tune their
On 31 Aug 2011, at 18:20, William A. Rowe Jr. wrote:
Note some additional improvements for a 'final' update 3 advisory…
Ack! Draft coming in half an hour or so,
Dw.
On 26 Aug 2011, at 18:05, William A. Rowe Jr. wrote:
On 8/26/2011 11:41 AM, Eric Covener wrote:
Should we bump the 5's in the draft advisory and/or code to a more
liberal #? At the very least for the 2.0 rewrite solution that will
return forbidden instead of full content?
Can we please
Suggestion for
http://people.apache.org/~dirkx/CVE-2011-3192.txt
to be sent to announce and the usual security places.
- Comments on weaken/strenghten 1.3 text
Happy to completely recant that it was vulnerable. Or happy to keep a
bit of a warning in there.
- Lots of
On 31 Aug 2011, at 21:03, Dirk-WIllem van Gulik wrote:
Suggestion for
http://people.apache.org/~dirkx/CVE-2011-3192.txt
to be sent to announce and the usual security places.
-Comments on weaken/strenghten 1.3 text
Happy to completely recant that it was vulnerable. Or
On Wednesday 31 August 2011, Joe Orton wrote:
On Tue, Aug 30, 2011 at 08:51:55PM +0200, Stefan Fritsch wrote:
The first regression report, though slightly too late for the
vote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825
The byterange_filter.c in the Debian update is
On Wednesday 31 August 2011, Jim Jagielski wrote:
Looking at the patch in 2.2.x; there is a lot of effort expended
deadling with apr_bucket_split() returning ENOTIMPL - that looks
unnecessary; the filter will only handle brigades containing
buckets with known length, and all such buckets
On 8/31/2011 4:00 PM, Stefan Fritsch wrote:
On Wednesday 31 August 2011, Joe Orton wrote:
Anything else to watch out for?
c) a request with a byterange beyond the end of the file used to
return 416 but now returns 200. This is a violation of a RFC2616
SHOULD. We didn't catch this when
On Aug 31, 2011, at 2:37 PM, s...@apache.org wrote:
Author: sf
Date: Wed Aug 31 21:37:38 2011
New Revision: 1163833
URL: http://svn.apache.org/viewvc?rev=1163833view=rev
Log:
Send a 206 response for a Range: bytes=0- request, even if 200 would be more
efficient.
200 is a better response
On 31 Aug 2011, at 21:07, Dirk-WIllem van Gulik wrote:
http://people.apache.org/~dirkx/CVE-2011-3192.txt
Off to bed now. If there is consensus we are 'done' then a vote on either of
these options would be of use
1 as above
2 as above but with complete reversal of the 1.3
Folks,
See below - for the 1.3 discussion - that suggest we should take it a notch
down:
On 31 Aug 2011, at 22:35, Munechika Sumikawa wrote:
We're currently discussing this - and will propably adjust the
announcement a bit. It is vulnerable in that it can suddenly take a
lot more CPU,
On Wednesday 31 August 2011, Roy T. Fielding wrote:
Author: sf
Date: Wed Aug 31 21:37:38 2011
New Revision: 1163833
URL: http://svn.apache.org/viewvc?rev=1163833view=rev
Log:
Send a 206 response for a Range: bytes=0- request, even if 200
would be more efficient.
200 is a
On 8/31/2011 6:06 PM, Stefan Fritsch wrote:
On Wednesday 31 August 2011, Roy T. Fielding wrote:
Author: sf
Date: Wed Aug 31 21:37:38 2011
New Revision: 1163833
URL: http://svn.apache.org/viewvc?rev=1163833view=rev
Log:
Send a 206 response for a Range: bytes=0- request, even if 200
would
On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote:
On 8/31/2011 6:06 PM, Stefan Fritsch wrote:
On Wednesday 31 August 2011, Roy T. Fielding wrote:
Author: sf
Date: Wed Aug 31 21:37:38 2011
New Revision: 1163833
URL: http://svn.apache.org/viewvc?rev=1163833view=rev
Log:
Send a 206
On 8/31/2011 4:16 PM, William A. Rowe Jr. wrote:
I've attempted to simply substitute the 2.2.19 filter code into the
2.0.64 http_protocol.c sources, and am unsure how far off these patches
are from what they need to be; there's been a significant amount of drift
and refactoring in the interim.
23 matches
Mail list logo
