You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/12/08 20:27:36 UTC

Re: mod_perl 1.99_11 test failures on PA-RISC HP-UX systems: taints issues

Jan Dubois wrote:
> We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
> with both HP C and GCC in both 32 bit and 64 bit mode.  They are not
> present on IPF systems in any of these combinations.
[...]
> All tests are with Apache 2.0.48, Perl 5.8.2 and mod_perl 1.99_11, all
> compiled with the same compiler.

Could you please test with the cvs version, so you don't bump onto bugs that 
were fixed already. Also please report bugs following 
http://perl.apache.org/bugs/ (we need the same report as perlbug).

Perl 5.8.2 is not ActivePerl?

>>>  api/slurp_filename................1..5
>>>  # Running under perl version 5.008002 for hpux
>>>  # Current time local: Thu Dec  4 11:07:29 2003
>>>  # Current time GMT:   Thu Dec  4 19:07:29 2003
>>>  # Using Test.pm version 1.24
>>>
>>>  [snip]
>>>
>>>  # testing : slurp filename tainted
>>>  # expected: (?-xism:Insecure dependency in eval)
>>>  # received:
>>>  not ok 2 
>>>
>>>  [snip]
>>>
>>>  # testing : slurp filename (perl) tainted
>>>  # expected: (?-xism:Insecure dependency in eval)
>>>  # received:
>>>  not ok 4
>>
>>In both of these test cases, data is being slurped in via some 
>>slurp_filename() and slurp_filename_perl() methods.  That data is then 
>>eval'd; both of the above tests fail because the eval() failures to emit a 
>>warning about "Insecure dependency in eval".  The difference between the 
>>two methods is that the second is a pure Perl implementation.

Since the pure perl version fails in the same way, this looks like a bug in 
perl. What do you get from running:

   % perl -Tle 'my $data = shift; eval { $received = eval $data }; print $@ ? 
"$@" : $received' foo

it should be:

   Insecure dependency in eval while running with -T switch at -e line 1.

and not

   foo

If the above works correctly, that would mean that the perl is not running 
under the taint mode, even though it was started with -T.

>>>  modperl/taint.....................1..4
>>>  # Running under perl version 5.008002 for hpux
>>>  # Current time local: Thu Dec  4 11:07:29 2003
>>>  # Current time GMT:   Thu Dec  4 19:07:29 2003
>>>  # Using Test.pm version 1.24
>>>  # testing : ${^TAINT}
>>>  # expected: 1
>>>  # received: 0
>>>  not ok 1
>>>
>>>  [snip]
>>>
>>>  # testing : $Apache::__T
>>>  # expected: 1
>>>  # received: 0
>>>  not ok 3
>>
>>I'm not sure (yet) why the taint variables are not set to 1.

I suppose this is related to the above. Both are set when -T is in effect.

I'll split this thread in 2 to separate different issues.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: mod_perl 1.99_11 test failures on PA-RISC HP-UX systems: taints issues

Posted by Jan Dubois <ja...@ActiveState.com>.
On Mon, 08 Dec 2003 11:27:36 -0800, Stas Bekman <st...@stason.org> wrote:

>Jan Dubois wrote:
>> We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
>> with both HP C and GCC in both 32 bit and 64 bit mode.  They are not
>> present on IPF systems in any of these combinations.
>[...]
>> All tests are with Apache 2.0.48, Perl 5.8.2 and mod_perl 1.99_11, all
>> compiled with the same compiler.
>
>Could you please test with the cvs version, so you don't bump onto bugs that 
>were fixed already. 

Please ignore this error report.  The test failures were due to a weird
configuration problem on that specific machine.  It was a little more
convoluted, but essentially we were running without a t/conf/extra.conf.in
file and even refreshing from version control didn't bring it back.

Cheers,
-Jan


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html