Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 72.14.220.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=WyRnl+tB+AIdqQrgh99JR4gJ0ASH8fSN8igzJ0dTvMjB5rYiNh0H4MyZrRXmmiui3o
         0anaNRO5xT8yKTFYU6Hd10UbGO5ic4hbO5hRnTePb0xJaiw4YRKCV5tK1j2HDkg2fGPy
         e6b54sBWyZLGSpvSVmgM+MkDIHOQN9hs71aj4=
MIME-Version: 1.0
In-Reply-To: <20090525074547.GA4975@redhat.com>
References: <cc67648e0905221412h202b807fg5b0355f0d034e20@mail.gmail.com>
	 <20090525074547.GA4975@redhat.com>
Date: Mon, 25 May 2009 12:03:23 -0400
Message-ID: <cc67648e0905250903w172f1d2dn56eea5a53ad6b2a4@mail.gmail.com>
Subject: Re: [concept PATCH] CVE-2009-1195 tweaks to provide binary
	compatibility for stable branches
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=000e0cd247d4f6d726046abebf35

--000e0cd247d4f6d726046abebf35
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, May 25, 2009 at 3:45 AM, Joe Orton <jorton@redhat.com> wrote:

> On Fri, May 22, 2009 at 05:12:31PM -0400, Jeff Trawick wrote:
> > (untested)
> >
> > ap_allow_options() is how applications, including our mod_include, access
> > the enabled options for a given request (other than evil apps which
> define
> > CORE_PRIVATE and locate the core_dir_config).  As this is a callable
> > function, it can map internal, hidden bitmaps as appropriate before
> > returning to the caller.
>
> Interesting idea!  I'm concerned this is going to be overly intrusive,
> what with requiring the changes to all uses of OPT_ALL internally.  Does
> it really matter what value of OPT_ALL is exposed to modules?
>
> (or specifically: does it break compatibility to change what value of
> OPT_ALL is exposed to modules?)


It seems safe to include the additional bit in OPT_ALL.


>
> Something simpler might be sufficient?


Err, I think you're looking for an overlap in sensibilities ;)  (We know
that answer is "yes" just as we also know that we can make it abundantly
clear (painful) throughout whether we are dealing with the internal or
external representation.)

I'm fine with your patch plus a bit of commentary in ap_allow_options().

Thanks a bunch!

--000e0cd247d4f6d726046abebf35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, May 25, 2009 at 3:45 AM, Joe Orton <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:jorton@redhat.com">jorton@redhat.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Fri, May 22, 2009 at 05:12:31PM -0400, Jeff Trawick wr=
ote:<br>
&gt; (untested)<br>
&gt;<br>
&gt; ap_allow_options() is how applications, including our mod_include, acc=
ess<br>
&gt; the enabled options for a given request (other than evil apps which de=
fine<br>
&gt; CORE_PRIVATE and locate the core_dir_config). =A0As this is a callable=
<br>
&gt; function, it can map internal, hidden bitmaps as appropriate before<br=
>
&gt; returning to the caller.<br>
<br>
</div>Interesting idea! =A0I&#39;m concerned this is going to be overly int=
rusive,<br>
what with requiring the changes to all uses of OPT_ALL internally. =A0Does<=
br>
it really matter what value of OPT_ALL is exposed to modules?<br>
<br>
(or specifically: does it break compatibility to change what value of<br>
OPT_ALL is exposed to modules?)</blockquote><div><br></div><div>It seems sa=
fe to include the additional bit in OPT_ALL.</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
<br>
<br>
Something simpler might be sufficient? =A0</blockquote><div><br></div><div>=
Err, I think you&#39;re looking for an overlap in sensibilities ;) =A0(We k=
now that answer is &quot;yes&quot; just as we also know that we can make it=
 abundantly clear (painful) throughout whether we are dealing with the inte=
rnal or external representation.)</div>
<div><br></div><div>I&#39;m fine with your patch plus a bit of commentary i=
n ap_allow_options().</div><div><br></div><div>Thanks a bunch!</div><div><b=
r></div></div>

--000e0cd247d4f6d726046abebf35--