Front page | perl.perl5.porters |
Postings from November 2009
2009/11/3 Mark Martinec <Mark.Martinec@ijs.si>:
>> Upstream claims it was solved by this commit
>>
>> 0abd0d78a73da1c4d13b1c700526b7e5d03b32d4 - disable non-unicode case
>> insensitive trie matching
>
> Where does this claim come from?
>
> I'm the reporter of the #69973 bug (closed by the above mentioned patch),
> but also have years of encounters (at amavisd-new and SpamAssassin) with
> cases where global variables $1, $2, etc get tainted by some complex
> expression, and subsequently start spreading taintedness in unrelated
> regular expressions - and I doubt these two cases have much in common.
>
> I tried several times to boil down a tainted-$1 case to a smallish
> test program, but I failed so far. Within a complex program I can
> pinpoint the expressions where $1 gets tainted and stays so, e.g.
> within IO::Handle::_open_mode_string:
>
> sub _open_mode_string {
> my ($mode) = @_;
> $mode =~ /^\+?(<|>>?)$/
> or $mode =~ s/^r(\+?)$/$1</
> or $mode =~ s/^w(\+?)$/$1>/
> or $mode =~ s/^a(\+?)$/$1>>/
> or croak "IO::Handle: bad open mode: $mode";
> $mode;
> }
>
> yet when this code is isolated in a test program the problem
> can no longer be reproduced - which is why I haven't reported
> the problem to perl bug tracking so far. If I remember correctly
> this nightmare started with perl 5.8.0.
>
> Workarounds range from avoiding use of r/w/a in IO::File::open,
> to isolating code sections by localizing $1, $2, ... to a close
> neighbourhood to where it is used. Using the local($1) within blocks
> turns out to be the best practice when writing new code to avoid
> future surprises.
Are you experiencing it on 5.10? And what about 5.11/blead?
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next