Re: To taint or not to taint?

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.

Comment on Re: To taint or not to taint?

Replies are listed 'Best First'.
Re^2: To taint or not to taint? by clinton (Priest) on Mar 19, 2009 at 15:34 UTC
For data coming from users, yes, absolutely agree. For internal data, eg paths from your config files which are readable only by root, would you still want this enabled? Would you do any real checks on these, or just untaint them blindly?	[reply]
Re^3: To taint or not to taint? by tilly (Archbishop) on Mar 19, 2009 at 15:40 UTC
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.	[reply]
Re^4: To taint or not to taint? by clinton (Priest) on Mar 19, 2009 at 15:44 UTC
Makes sense. Which has made me think, I could change my config loader to automatically untaint all the data it loads from a file if the file is writable only by the current user, no?	[reply]
Re^5: To taint or not to taint? by tilly (Archbishop) on Mar 19, 2009 at 15:46 UTC


laziness, impatience, and hubris
	PerlMonks