httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [concept PATCH] CVE-2009-1195 tweaks to provide binary compatibility for stable branches
Date Mon, 25 May 2009 16:03:23 GMT
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!

Mime
View raw message