On Fri, May 22, 2009 at 5:10 PM, William A. Rowe, Jr.
wrote:
> Jeff Trawick wrote:
> >
> > Backing up a bit...
> >
> > I originally thought we could map bit values in 2.2.x to avoid affecting
> > modules, but that isn't possible since includes-with-exec is two bits
> > instead of one.
>
> Hold on.
Jeff Trawick wrote:
>
> Backing up a bit...
>
> I originally thought we could map bit values in 2.2.x to avoid affecting
> modules, but that isn't possible since includes-with-exec is two bits
> instead of one.
Hold on... I think this can still work;
* Retain new true 'Includes' bit as old In
On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick wrote:
>
>
> On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. > wrote:
>
>> Joe Orton wrote:
>> >
>> > 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,
On Fri, May 22, 2009 at 4:20 PM, Bruce Johnson
wrote:
> My script has a
>
> use POSIX;
>
> in it, which is filling my error log with several hundred error lines:
>
> Constant subroutine
> ModPerl::ROOT::ModPerl::PerlRunPrefork::home_oraweb_perl_badgers_makebadges_2epl::_POSIX_CHILD_MAX
> redefined
On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr.
wrote:
> Joe Orton wrote:
> >
> > 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
My script has a
use POSIX;
in it, which is filling my error log with several hundred error lines:
Constant subroutine
ModPerl
::ROOT
::ModPerl
::PerlRunPrefork
::home_oraweb_perl_badgers_makebadges_2epl::_POSIX_CHILD_MAX redefined
at /opt/lampp/lib/perl5/site_perl/5.10.0/i686-linux/ModP
On Fri, May 22, 2009 at 2:46 PM, Torsten Foertsch
wrote:
> On Fri 22 May 2009, Jeff Trawick wrote:
> > Hmmm, after trying to use what seems like a cool feature, I find that
> > mod_perl was never taught to use the Apache 2's mod_include plug-in
> > interface.
>
> AFAIK, that is provided by Geoff's
Joe Orton wrote:
>
> 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 C langauge p
On Fri 22 May 2009, Jeff Trawick wrote:
> Hmmm, after trying to use what seems like a cool feature, I find that
> mod_perl was never taught to use the Apache 2's mod_include plug-in
> interface.
AFAIK, that is provided by Geoff's CPAN module Apache::IncludeHook or
so.
Torsten
--
Need professio
On Fri, May 22, 2009 at 10:17 AM, Jeff Trawick wrote:
>
> On Thu, May 21, 2009 at 3:25 PM, Jeff Trawick wrote:
>>
>> On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr.
>> wrote:
>>>
>>> Jeff Trawick wrote:
>>> > Does somebody else care to share their opinion on this? Which of these
>>> > are
On Thu, May 21, 2009 at 3:25 PM, Jeff Trawick wrote:
>
>
> On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr. > wrote:
>
>> Jeff Trawick wrote:
>> > Does somebody else care to share their opinion on this? Which of these
>> > are okay?
>> >
>> > - existing mod_perl releases (and potentially o
On Fri, May 22, 2009 at 05:26:07PM +0100, Joe Orton wrote:
> Attaching my original analysis for security@ which hopefully answers
> that question ;)
attempt 2
I've now had a deeper look into this. I can't see a way to fix the
problem without changing the semantics of the OPT_ bits used, as I
On Thu, May 21, 2009 at 02:39:57PM -0400, Jeff Trawick wrote:
> On Wed, May 20, 2009 at 8:53 AM, Joe Orton 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 c
13 matches
Mail list logo
