On Thu, Dec 8, 2016 at 7:16 PM, William A Rowe Jr wrote:
>
> It does raise the question again of whether the httpd project can distribute
> a source code package on www.apache.org/dist/httpd/ which is not voted
> on by the project, and whether it violates the spirit of the pmc consensus
> to no lo
On Thu, Dec 8, 2016 at 12:16 PM, William A Rowe Jr
wrote:
> On Thu, Dec 8, 2016 at 12:03 PM, Jim Jagielski wrote:
>
>> AFAICT there is no consensus. But is this really a blocker?
>
>
> I don't know, expat is at 2.2.0 and PCRE is at 8.39 with significant
> vulnerability
> fixes (everyone seems ve
On Thu, Dec 8, 2016 at 1:57 PM, wrote:
> Author: covener
> Date: Thu Dec 8 19:57:57 2016
> New Revision: 1773293
>
> URL: http://svn.apache.org/viewvc?rev=1773293&view=rev
> Log:
> change error handling for bad resp headers
>
> - avoid looping between ap_die and the http filter
> - remove the
On 12/08/2016 02:06 PM, Eric Covener wrote:
On Thu, Dec 8, 2016 at 4:55 PM, Jacob Champion wrote:
Hmm, I suppose that if something like Transfer-/Content-Encoding is one of
the headers to get axed here, we'll end up breaking the protocol entirely if
and when we push out the original response bo
On Thu, Dec 8, 2016 at 4:55 PM, Jacob Champion wrote:
> Hmm, I suppose that if something like Transfer-/Content-Encoding is one of
> the headers to get axed here, we'll end up breaking the protocol entirely if
> and when we push out the original response body...
Probably SOL already if they have
On 12/08/2016 11:57 AM, cove...@apache.org wrote:
Author: covener
Date: Thu Dec 8 19:57:57 2016
New Revision: 1773293
URL: http://svn.apache.org/viewvc?rev=1773293&view=rev
Log:
change error handling for bad resp headers
- avoid looping between ap_die and the http filter
- remove the header
It should be complete enough to apply complete to httpd-2.4.x.
On Dec 8, 2016 1:32 PM, "Eric Covener" wrote:
> On Wed, Dec 7, 2016 at 6:40 PM, wrote:
> > Author: wrowe
> > Date: Wed Dec 7 23:40:20 2016
> > New Revision: 1773163
> >
> > URL: http://svn.apache.org/viewvc?rev=1773163&view=rev
On Thu, Dec 8, 2016 at 2:34 PM, Jacob Champion wrote:
> On 12/08/2016 11:14 AM, Eric Covener wrote:
>>
>> On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr
>> wrote:
>>>
>>> Still, I think we want to add a guard to rip out the offending header
>>> and not ap_die() in handling a 500 error, that's
On 12/08/2016 11:14 AM, Eric Covener wrote:
On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr wrote:
Still, I think we want to add a guard to rip out the offending header
and not ap_die() in handling a 500 error, that's quite the loop, and
if you could create the problem, so can another unsuspe
On Wed, Dec 7, 2016 at 6:40 PM, wrote:
> Author: wrowe
> Date: Wed Dec 7 23:40:20 2016
> New Revision: 1773163
>
> URL: http://svn.apache.org/viewvc?rev=1773163&view=rev
> Log:
> After eliminating unusual whitespace in Unsafe mode (e.g. \f \v), we are left
> with the same behavior in both of the
On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr wrote:
> Still, I think we want to add a guard to rip out the offending header
> and not ap_die() in handling a 500 error, that's quite the loop, and
> if you could create the problem, so can another unsuspecting admin.
Is 500 status code and stat
On Thu, Dec 8, 2016 at 12:49 PM, Eric Covener wrote:
> On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote:
> > This is even after trying to zap the offending header before ap_die.
>
> I think this is more about how I am injecting the bad characters -- It
> is re-running after the ap_die.
>
Stil
On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote:
> This is even after trying to zap the offending header before ap_die.
I think this is more about how I am injecting the bad characters -- It
is re-running after the ap_die.
--
Eric Covener
cove...@gmail.com
Scratch that...
Instead, I plan on doing it on Monday, to provide some additional
time for some things to get locked down and resolved.
My apologies for those waiting for 2.4.24...
> On Dec 8, 2016, at 9:55 AM, Jim Jagielski wrote:
>
> Things are looking good for a T&R of 2.4.24 sometime late
I should mention I was actually "on" trunk because I thought there'd
be a quick fix. But the relevant stuff is recently backported
On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote:
> I am playing with check_headers() and injecting bad characters, and I
> am getting some looping:
>
> #2155 0x00
I am playing with check_headers() and injecting bad characters, and I
am getting some looping:
#2155 0x0048af80 in ap_http_header_filter (f=0x7fffc80061d0,
b=0x7fffc09c2bd8) at http_filters.c:1262
#2156 0x004396d0 in ap_pass_brigade (next=0x7fffc80061d0,
bb=0x7fffc09c2bd8) at util_
On Thu, Dec 8, 2016 at 12:03 PM, Jim Jagielski wrote:
> AFAICT there is no consensus. But is this really a blocker?
I don't know, expat is at 2.2.0 and PCRE is at 8.39 with significant
vulnerability
fixes (everyone seems very enamored with fuzz generators this past few
years.)
It doesn't block
AFAICT there is no consensus. But is this really a
blocker?
> On Dec 8, 2016, at 12:38 PM, William A Rowe Jr wrote:
>
> On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski wrote:
> Things are looking good for a T&R of 2.4.24 sometime late
> today.
>
> If you have any issues or concerns, let me know
On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski wrote:
> Things are looking good for a T&R of 2.4.24 sometime late
> today.
>
> If you have any issues or concerns, let me know asap.
>
Do we have any consensus on dropping the stale and vulnerable
expat or pcre packages from the pretending-not-to-be
I've beaten my head against this wall for a bit longer, and came up with
several places where pcre2 changed return types for void *what query
interogations (especially from int to uint32, badness on x86_64-linux).
The attached patch picks up these bad void * type assignments. Still
no tremendous i
Things are looking good for a T&R of 2.4.24 sometime late
today.
If you have any issues or concerns, let me know asap.
Hi everybody,
thanks a lot for the useful feedback. Quoting Jacob from another thread:
2016-12-08 0:04 GMT+01:00 Jacob Champion :
>
>
> I thought the original bug report was related to 204 processing only, and
> then Luca asked if his patch should also include informational-status
> checks as wel
> Am 08.12.2016 um 11:25 schrieb Yann Ylavic :
>
> On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr wrote:
>> On Dec 7, 2016 6:23 PM, "Jacob Champion" wrote:
>>
>> On 12/07/2016 04:00 PM, William A Rowe Jr wrote:
>>>
>>> Consider for a moment the case of an HTTP/1.1 upgrade request
>>> unrec
On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr wrote:
> On Dec 7, 2016 6:23 PM, "Jacob Champion" wrote:
>
> On 12/07/2016 04:00 PM, William A Rowe Jr wrote:
>>
>> Consider for a moment the case of an HTTP/1.1 upgrade request
>> unrecognized by a proxy agent.
>
>
> It was my understanding that
24 matches
Mail list logo
