Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Locale-Maketext CPAN distribution.

Report information
The Basics
Id: 40727
Status: resolved
Priority: 0/
Queue: Locale-Maketext

People
Owner: ferreira [...] shoo.cpan.org
Requestors: FANY [...] cpan.org
Cc: 460423 [...] rt.noris.net
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 1.09
  • 1.13
Fixed in: 1.15_01



CC: 460423 [...] rt.noris.net
Subject: ininite loop in Locale::Maketext::Guts::_compile() when working with tainted values
A CGI application I'm writing was just running in an infinite loop that I could track down in Locale::Maketext::Guts::_compile(). The reason is that several (including current) versions of the Perl interpreter seem to have a bug with pattern matching operations involving \G on tainted values, cmp. my perl bug report #60378: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - pos() and regex matching with \G does not work if a tainted value is passed to a sub routine: $ perl -Tle '$_=shift; /\G(.*)/g; print pos || "-"' foo 3 $ perl -le 'x(shift); sub x { $_[0] =~ /\G(.*)/g; print pos $_[0] || "-" }' foo 3 $ perl -Tle 'x(shift); sub x { $_[0] =~ /\G(.*)/g; print pos $_[0] || "-" }' foo - This e.g. causes infinite loops in Locale::Maketext::Guts::_compile(). It works, however, if the value is assigned to a variable first and then this variable is used for the matching operation: $ perl -Tle 'x(shift); sub x { my $s = shift; $s =~ /\G(.*)/g; print pos $s || "-" }' foo 3 The issue not only affects the perl version mentioned below but also the standard perl v5.8.8 interpreter built for i486-linux-gnu-thread-multi on Debian/Etch and thus probably other versions, too. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Even if this is considered a Perl bug and will hopefully be fixed some day, I think it would be reasonable to have a workaround in Locale::Maketext::Guts::compile(), too, in order to have the module work with current Perl versions. A simple solution would be not to match on $_[1] but to assign "my $var = $_[1];" before and then use $var for the matching operation. BTW, if you're wondering how a tainted value gets there anyway: One of my templates refers to my CGI::Application's current runmode, which is submitted by the client. I was really puzzled at first, because my application worked for one langugage, which I use Locale::Maketext::Lexicon::Gettext for, but got stuck for certain (tainted) values in conjunction with Locale::Maketext::Lexicon::Auto when switching to another language. Regards, fany
On Do. 06. Nov. 2008, 13:14:41, FANY wrote: Show quoted text
> Even if this is considered a Perl bug and will hopefully be fixed some > day,
However, it has not been fixed since I had first reported it over four years ago: http://rt.perl.org/rt3/Public/Bug/Display.html?id=27344
This is a seriously annoying bug which has cost me hours this afternoon (wish I'd looked at rt more carefully first instead of just glancing at it). I hope the workaround can be introduced to Locale::MakeText as the original Perl bug does not look like getting fixed soon. I'd just like to add that if you are not using bracketed expressions (as we are not) there would be no need for the while loop on the regexp in the first place. Being able to turn off bracketing support would have saved me quite a bit today. Martin -- Martin J. Evans Wetherby, UK
A suggested patch for this is on github: http://github.com/toddr/Locale- Maketext/commit/28943861c738e648ca8e4542405a30c6f1004f7c.patch
Subject: patch.txt
diff --git a/lib/Locale/Maketext.pm b/lib/Locale/Maketext.pm index 9bb9281..9c91d15 100644 --- a/lib/Locale/Maketext.pm +++ b/lib/Locale/Maketext.pm @@ -11,7 +11,7 @@ use I18N::LangTags::Detect (); BEGIN { unless(defined &DEBUG) { *DEBUG = sub () {0} } } # define the constant 'DEBUG' at compile-time -$VERSION = '1.13_88'; +$VERSION = '1.13_89'; $VERSION = eval $VERSION; @ISA = (); @@ -518,7 +518,8 @@ sub _compile { # start out outside a group my($in_group, $m, @params) = (0); # scratch - while($_[1] =~ # Iterate over chunks. + my $under_one = $_[1]; # There are taint issues using regex on $_ - perlbug 60378,27344 + while($under_one =~ # Iterate over chunks. m/\G( [^\~\[\]]+ # non-~[] stuff | @@ -540,10 +541,10 @@ sub _compile { # preceding literal. if($in_group) { if($1 eq '') { - $target->_die_pointing($_[1], 'Unterminated bracket group'); + $target->_die_pointing($under_one, 'Unterminated bracket group'); } else { - $target->_die_pointing($_[1], 'You can\'t nest bracket groups'); + $target->_die_pointing($under_one, 'You can\'t nest bracket groups'); } } else { @@ -553,7 +554,7 @@ sub _compile { else { $in_group = 1; } - die "How come \@c is empty?? in <$_[1]>" unless @c; # sanity + die "How come \@c is empty?? in <$under_one>" unless @c; # sanity if(length $c[-1]) { # Now actually processing the preceding literal $big_pile .= $c[-1]; @@ -632,7 +633,7 @@ sub _compile { # Yes, it even supports the demented (and undocumented?) # $obj->Foo::bar(...) syntax. $target->_die_pointing( - $_[1], q{Can't use "SUPER::" in a bracket-group method}, + $under_one, q{Can't use "SUPER::" in a bracket-group method}, 2 + length($c[-1]) ) if $m =~ m/^SUPER::/s; @@ -645,7 +646,7 @@ sub _compile { else { # TODO: implement something? or just too icky to consider? $target->_die_pointing( - $_[1], + $under_one, "Can't use \"$m\" as a method name in bracket group", 2 + length($c[-1]) ); @@ -686,7 +687,7 @@ sub _compile { push @c, ''; } else { - $target->_die_pointing($_[1], q{Unbalanced ']'}); + $target->_die_pointing($under_one, q{Unbalanced ']'}); } } -- 1.6.4.3
This was accepted in blead by p5p commit e9c9ffcae4a8b5820dabb04674b85bb5195fcfc4 Author: Todd Rinaldo <toddr@cpanel.net> Date: Sat Sep 25 11:20:10 2010 -0700 This patch with tests resolves CPAN RT #40727. The issue is an infi- nite loop during _compile when working with tainted values. The issue was triggered by perlbugs 60378,27344. Both have been resolved but they are still broken in perl 5.12.x and earlier. The patch simply assigns $_[1] to a variable and uses that from then on.
1.15_02 is the RC for 1.16. No issues so far. closing ticket.