Taint mode is a terrible misfeature and modern code should not use it. It's one of those things that makes people think "it's annoying and makes me do additiona

Taint mode is a terrible misfeature and modern code should not use it. It's one of those things that makes people think "it's annoying and makes me do additional work so surely it improves the security". No, it doesn't. For those who are unware what taint mode exactly is: when it's enabled, a string may have a hidden "tainted" flag. Passing a tainted string to many (but not all) built-in functions will result in an exception. Many built-ins return tainted strings, additionally all strings in @ARGV (cli parameters) and %ENV (env variables) are tainted. You can get an untainted string by accessing a tainted string through a regex capture group ($1, $2 etc.). Taint mode is global, so it affects everything, including third party modules. You may ask "how do I even validate my environmental variables? What's the difference between valid and invalid PATH?". Well, you can't. That's why programs using taint mode are often littered with code like: my($untainted) = $foo =~ /^(.*)$/ The worst thing is that you never know whether a function from a third party (CPAN?) module will return a tainted string or not. It may differ between platforms! For example, File::Spec is sometimes returning tainted strings on unixes, but not on Windows (or the other way around, I'm not sure!). In practice that means you will have to run your program, check if it throws an exception, and if it does, you have to use the above no-op "validation" regex. Well, that assumes that the said third party code works in taint mode. If it wasn't tested with it, it's possible that it won't work at all and there's nothing you can do about it.