https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6310
--- Comment #10 from Mark Martinec <[email protected]> 2010-03-25 12:40:10 UTC --- Btw, fixed in perl 5.12 / 5.13: -------- Now fixed by commit 447ee1343739cf8e34c4ff1ba9b30eae75c3f1ab in branch davem/post-5.12, which should be merged back into blead once 5.12 has been released, and thus appear in 5.13 onwards: commit 447ee1343739cf8e34c4ff1ba9b30eae75c3f1ab Author: David Mitchell <[email protected]> AuthorDate: Thu Mar 25 10:56:35 2010 +0000 Commit: David Mitchell <[email protected]> CommitDate: Thu Mar 25 10:56:35 2010 +0000 RT #67962: $1 treated as tainted in untainted match Fix the issue in the following: use re 'taint'; $tainted =~ /(...)/; # $1 now correctly tainted $untainted =~ s/(...)/$1/; # $untainted now incorrectly tainted The problem stems from when $1 is updated. pp_substcont, which is called after the replacement expression has been evaluated, checks the returned expression for taintedness, and if so, taints the variable being substituted. For a substitution like s/(...)/x$1/ this works fine: the expression "x".$1 causes $1's get magic to be called, which sets $1 based on the recent match, and is marked as not tainted. Thus the returned expression is untainted. In the variant s/(...)/$1/, the returned value on the stack is $1 itself, and its get magic hasn't been called yet. So it still has the tainted flag from the previous pattern. The solution is to mg_get the returned expression before testing for taintedness. Affected files ... M pp_ctl.c M t/op/taint.t -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
