There is probably code somewhere that takes advantage of that fact, and under 5.10.0 that code is now less secure.

So, someone, somewhere might be unpacking a tainted string and relying upon the resultants continued tainted status to prevent them from ... ?

I agree that departure from the documented behaviour is not good, but I would be a little leary about labelling it as a "security risk".

Relying on the tainted state of anything is less secure than being certain to clean it properly. Taint mode is a safety net, and now there's an undocumented hole in the net.

This might not be a common issue, but someone somewhere might get bit by it. It only takes one vocal person who gets bit by it to further the "Perl is insecure" meme, no matter that it's the safety net he was counting on that failed.

More philosophically, if the docs and tutorials are going to tout Taint mode as a general tool for improving security, then the security docs covering that should be very accurate and precise. That someone gets burned by following directions about the enhanced security layer offered by a broadly recommended module is just a bad way for an application's security to fail.

You might take issue with Taint.pm being widely suggested as a security improvement, but I think it would be hard to argue that isn't the case. So long as it is promoted, it should provide at least what the docs specifically say it does.

I'll try a different tack. In order for this to be more than a documentation problem, a piece of < 5.10 code that works correctly, would have to fail when run on 5.10.

So, let's try and construct a piece of code that would meet that criteria.

1. We need a piece of tainted data:

   my $tainted = <STDIN>;
   [download]

2. Next, we need to pack that data:

   my $stillTainted = pack 'a*', $tainted;
   [download]

3. Finally, we need to use the still tainted data to do something that would have rejected it:

   open my $fh, '>', $stillTainted or die $!;
   [download]

And there's the problem. With < 5.10, that will always fail with Insecure dependency in open while running with -T switch ..., because they never did anything to untaint it. And any usage that wouldn't fail under < 5.10, still won't fail (and will still be secure) under 5.10.

The above sequence wouldn't fail under 5.10, but the problem only affects new code, and that can be addressed by a documentation change (if that's the right way to go), rather than a code change.

My point was that it doesn't make any existing (pre-5.10) code that works, less secure when that code is moved to 5.10, because if it worked securly pre-5.10, it'll still work securely.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."