Learning the ins and outs of HTTP and how to prevent easy exploitation is another thing.

Not running taint checks is clearly a security flaw. On the other hand, I can't really entertain the idea that not running with strictures and warnings is a bug.

Turning off warnings in CGI scripts can stop your logs blowing out. I agree that a warning should be acted upon at the earliest opportunity and I ensure that all my programs are warning-free, but a warning is just that, a warning. On the other hand running out of space on your logging device is catastrophic. You have to make a tradeoff between paranoia and pragmatism.

And remember that strict.pm guards against three things: symbolic references, bareword "poetry" subs and undeclared variables. I think most people just 'use strict' to help them make sure they always use lexical variables. People rarely use package variables these days and even less people use symbolic references (by accident or otherwise).

So while I always use strict in my programs, I do not consider a program that doesn't as being inferior. Doing so is not a bug.

While NOT using Taint in a CGI script is a potential security hole, not using Warnings and Strictures is neither a security hole nor a bug.

Warnings and Strictures should only be used during development. They don't really serve a useful purpose in production code. If you're relying on them to catch errors in live CGI scripts then it could have disastrous effects *. CGI scripts are a special entity and knowing that if the worse can happen it will, coding for those kind of eventualities, so that scripts report and handle errors safely, can save a lot of grief. In fact leaving use warnings and use strict uncommented in a CGI script can be an unnecessary drain on your webserver.

Tainting doesn't necessarily require you to have -T at the top of your script. However, it does mean you should code assuming anything coming from the outside world is harmful.

* I have been witness to several sites exposing their DB access username/password once a fatal error occurs.

--
Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/

Warnings and Strictures should only be used during development. They don't really serve a useful purpose in production code.

I totally and utterly disagree.

Warnings and strictures are there to catch and prevent errors during development and help you trace errors in production. Seeing that a previously warning free script all of a sudden starts generating warnings is sign of a serious bug that should be resolved immediately. Disabling warnings and strictures would mean that you never knew a bug existed.

Specifically disabling specific warnings or strictures for limited scopes of your code is perfectly ok. Turing off warnings and stricutres in code that was written with it (most of CPAN) is irresponsible and dangerous.

I have been witness to several sites exposing their DB access username/password once a fatal error occurs.

So because these sites did something foolish you advocate removing your ability to see that the program is doing something unexpected? That doesnt make sense to me.


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}