On Wed, 2014-09-24 at 22:15 +0200, Rainer Jung wrote:
One could try to sanitize env var contents in ap_create_environment()
though. Currently we do sanitize variable names there. But there's no
generally good pattern for the value sanitizing.
This is a revisiting of the classic perl/cgi
On Thu, Sep 25, 2014 at 10:53 AM, Nick Kew n...@apache.org wrote:
The exploit is said to be any env var value looking like
() { something }; problematicPart
That's a pattern that can be regexp-matched. The regexp
could be hardwired in under the name CVE-2014-6271
for sysops who want an
I agree, but one-off, specific-case hacks like that are
usually more trouble then they are worth, imo at least.
What if we find another attack vector? Then we add another
special case, etc...
IMO, this is outside of httpd's realm to deal with...
Just my 2c
On Sep 24, 2014, at 4:21 PM, Rainer
httpd side:
serf to me is the wrong question.
http/2.0 in the simplest implementation is just another protocol to
httpd. We have the constructs to handle it, kinda. Improvements to
async support in various bits will help.
However our constructs about requests and connections (and their
pools)
On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote:
APR:
Considering that before we know it, http/2.0 will
be here, and ignoring httpd for the time being,
what features/additions do we see as being needed
to support http/2.0 from an APR library level? How do
we compare w/
On Thu, 25 Sep 2014 05:26:38 -0700
Paul Querna p...@querna.org wrote:
On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com
wrote:
APR:
Considering that before we know it, http/2.0 will
be here, and ignoring httpd for the time being,
what features/additions do we see as being
On 25 Sep 2014, at 2:13 PM, Paul Querna p...@querna.org wrote:
http/2.0 in the simplest implementation is just another protocol to
httpd. We have the constructs to handle it, kinda. Improvements to
async support in various bits will help.
However our constructs about requests and
On 09/25/2014 01:03 PM, Jim Jagielski wrote:
I agree, but one-off, specific-case hacks like that are
usually more trouble then they are worth, imo at least.
What if we find another attack vector? Then we add another
special case, etc...
IMO, this is outside of httpd's realm to deal
