On Thu, May 21, 2009 at 02:39:57PM -0400, Jeff Trawick wrote: > On Wed, May 20, 2009 at 8:53 AM, Joe Orton <jor...@redhat.com> wrote: > > Given that the semantics of the options has changed, I don't think it's > > worth changing httpd to maintain any pretence of compile-time or > > run-time compatibility here. Any code using the OPT_* constants as > > exposed by mod_perl cannot work as expected any more. > > Is the change in semantics required to fix the bug, or is it simply the > current implementation?
Attaching my original analysis for security@ which hopefully answers that question ;) Having thought about this longer, I do agree that it would be reasonable to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it turns out we're out of bits - allow_options_t is an unsigned char and we're using 2^0 through 2^7 already. :( The only available option is to #define OPT_INCNOEXEC to some bogus string or something; not sure I like that much better than just a clean break. Worth noting: for any mod_perl-based code which tests only OPT_INCLUDE for "is SSI enabled", that will continue to be compatible with the new implementation, modulo mod_perl build failures. The only issue is with code which needs to differentiate between SSI-with-exec and -without. Regards, Joe
