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.

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...}

In CGI, advertising there is a problem to the user, in such a way as to expose your security, is bad. If you have a site that throws up warnings and errors, then you have either not tested it properly or haven't coded to catch errors and deal with them well enough to (a) allow the user to know there has been a problem and apologise for the inconvience and (b) log and report the warnings/errors in a responsible manner.

Blindly assuming warnings and strictures are going to save you is not a good design of a CGI application. If a "warning free script" starts sprouting warnings in a live situation, then that strikes me as the code not having been tested for the environment it will be deployed in. Also I think you are referring to these messages inacurately. Warnings are just that, warnings. They *might* indicate there is a serious bug, but not necessarily. If a warning was to indicate a serious bug, why tell the user? Why just write it to the error log, that might not get looked at for days, weeks or longer. Don't rely on the user to tell you something has gone wrong.

If warnings and errors are continually being written to log files, then you are wasting resources in CPU, disc space and time. Reporting errors so that they can be resolved quickly, without causing the site to throw error reports at the user or worse continually timing out (due to too many warning messages being written to log files), is a much better way to maintain a healthy site.

I too wouldn't advocate turning off warnings and strictures in all your CPAN modules, however, the likelihood that the fault will lie there is low. I should have qualified the statement you highlighted from my original post though. I don't advocate using warnings and strictures in production CGI scripts. In non-CGI and development CGI I do, as this is where the users/programmers generally do need to see warnings/errors as they happen.

Flaws like exposing usernames/passwords might be rare, but they highlight that relying on warnings and strictures are not part of good CGI design. To the general user, the usefulness of M$'s blue screen of death is zilch. Web pages that act in a similar way do themselves no favours. It's why 404s (usually) return a nice error page, rather than system error messages telling you the file in your (now fully qualified) directory doesn't exist.

Don't get me wrong, warnings and strict are good things to use. But use them responsibly, not to do the work for you.

In the post I was replying to, the AM claimed that "not using strict/warnings/tainting are all bugs/security holes". My point was that warnings and strict are neither, as from a user perspective they don't need to know the specifics of an error, only to know you are dealing with it. Poor testing is a poor excuse for relying on the user to tell you of errors.

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