which kinda defeats the purpose. Almost always, I found that the stuff I was untainting would have required root access to mess with anyway, and so I gave up on taint mode. The places where exploits were possible, I added relevant code to deal with those particular situations, and all data coming from the user gets validated.

Of course, I may have missed some situations. Maybe I'm being naive. But is enabling taint mode by default the answer to that? Doesn't it mean that, for most people, their code will just fill up with:

When I write short do-one-task-once scripts I don't bother with tainting.

When I write CGI scripts I'm paranoid and enable taint checking, and it's not much of a hassle since my applications typically only talk to the database.

If I have to call external programs from CGI scripts my paranoia is even bigger, and I verify all parameter from the outside anyway (with regexes and white listing hashes), so it doesn't cause me any trouble.

In fact two years ago I enabled taint checking for a collection of CGI scripts, and needed only one minor modification.

Do you trust your users? If not, then does what you're doing lead to any potential risks at all? If so, then do you consider your code perfect? If not then why would you give up a very cheap reminder that could catch an accidental severe mistake?

My answer to the first question generally depends on whether my programs are facing the general internet or are internal to whoever I am working for. I tend to be a little paranoid in my answer to the second. The answers to the last two are that my code is not perfect, and I love cheap reminders that catch real mistakes.

I therefore tend to use taint mode exactly when my code is facing the general internet.

The point of taint checking is to make the programmer decide what is risky. Obviously the config file that is that protected is safe, and so blindly untainting it is reasonable. That is the cost of the double-check that the checks I care about on my users really are being done as I think they are.

If your world is limited, and almost all you do is being a web monkey, by all means, drone yourself to always use taint.

I only use taint if my program has to potential to do something the caller isn't able to - and if the caller is potentially hostile. But I write a large numbers of programs that run under the same privileges the user already has.

I think one should always think whether you should use taint mode or not. And use it when appropriate. Neither "always use taint" nor "never use taint" appeals to me.

I like to write code that works under taint because it increases the number of contexts where my code can be used.

You may already be aware of this, but one can significantly reduce the number of pointless taint complaints simply by setting $ENV{PATH}=''; $ENV{CDPATH}=''; or other known (untainted/detainted) value. This applies to a few other variables, like IFS, as well. See perlsec for details.

In a nutshell, Taint Mode is a collection of specific restrictions in Perl that collectively help you to write safer scripts by forcing you to think more carefully about how your script uses information. Specifically, it will prevent you from using or relying on data that was provided from outside the script within any action that will in turn affect something else outside of your script--unless you take specific steps to "clean" that data, first.
Have a look at "Introduction to Perl's Taint Mode" at http://www.webreference.com/programming/perl/taint/ for a better understanding.