On Monday 29 September 2014 10:07:40, Nick Kew wrote:
> Yes. It's catching potential attacks in r->headers_in.
> The rest is paranoia-mode afterthoughts:
> PATH_INFO/QUERY_STRING because they could contain something
> interesting, subprocess_env just "because it's there" (there's
> a code comment
On Mon, 2014-09-29 at 09:43 +0200, Yann Ylavic wrote:
> On Mon, Sep 29, 2014 at 7:59 AM, Nick Kew wrote:
> > On Sun, 2014-09-28 at 23:10 +0200, Rainer Jung wrote:
> >
> >> IMHO it is a useful approach. Whan I looked at the CGI topic, I noticed
> >> that the safest thing is cleaning up in ap_create
Am 29.09.2014 um 09:56 schrieb Issac Goldstand:
On 29/09/2014 00:00, Rainer Jung wrote:
Am 28.09.2014 um 09:07 schrieb Issac Goldstand:
-0
While I love the code that's been come up with, this would be akin to
trying to have patched httpd to deal with Heartbleed.
I can't see any real use-case
On 29/09/2014 00:00, Rainer Jung wrote:
> Am 28.09.2014 um 09:07 schrieb Issac Goldstand:
>> -0
>>
>> While I love the code that's been come up with, this would be akin to
>> trying to have patched httpd to deal with Heartbleed.
>>
>> I can't see any real use-case where a user would get a patched h
On Mon, Sep 29, 2014 at 7:59 AM, Nick Kew wrote:
> On Sun, 2014-09-28 at 23:10 +0200, Rainer Jung wrote:
>
>> IMHO it is a useful approach. Whan I looked at the CGI topic, I noticed
>> that the safest thing is cleaning up in ap_create_environment(), because
>> you can be sure to get every env var
