in reply to Why do I need -w in a cgi script

As others have said, there must be something else wrong with your script - -w will not cause your script to not run. Here's what
perldoc perlrun
says about the -w switch:
-w prints warnings about dubious constructs, such as variable + names that are mentioned only once and scalar variables that are + used before being set, redefined subroutines, references to und +efined filehandles or filehandles opened read-only that you are a +ttempt- ing to write on, values used as a number that doesn’t look + like numbers, using an array as though it were a scalar, if you +r sub- routines recurse more than 100 deep, and innumerable other + things.
IMHO, you should always use the "-w" switch - I do :-)

HTH.

Replies are listed 'Best First'.
Re: Why do I need -w in a cgi script
by jonadab (Parson) on Oct 09, 2003 at 16:14 UTC
    IMHO, you should always use the "-w" switch - I do

    For testing, always use -w. However, if you reach a point where you're no longer doing anything actively in terms of testing or changing the script, it doesn't hurt to turn it off for production use. The real question is whether it's reasonable to turn off Taint checking for production use, or whether it should always be left on, and I think this depends on your specific circumstances. I leave it on, personally.


    $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

      The real question is whether it's reasonable to turn off Taint checking for production use, or whether it should always be left on, and I think this depends on your specific circumstances. I leave it on, personally.

      Taint checking is a security tool, not a development tool. Unless security is unimportant in production, do not remove it.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        Taint checking is a security tool, not a development tool. Unless security is unimportant in production, do not remove it.

        Oh? I know it's a run-time mechanism, but I was under the impression that if you were doing anything unsafe with tainted data, a reasonable amount of testing would flush that out, and you'd fix it, and subsequently you would not be doing unsafe things with tainted data, provided the script and the taintedness of its data don't change and that you tested all the code pathways in testing. I've been leaving it turned on, because not forgetting to turn it back on if I make changes is more important to me than performance, but I'd be interested in an explanation of how my thinking in this area is mistaken.


        $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
      Whether to leave on taint checking or not in production code isn't a question. Removing it in production isn't an option. It's like saying you keep safety belts on while preparing your car, but you remove them from your car when you're about to drive cross-country.

      Abigail

        I tentatively disagree

        Once you have verified that your script runs with taint-checking, then taint-checking serves no further purpose

        To correct your analogy, taint-checking is the irritating voice that tells you when your seat-belt is undone - once you fasten your seat-belt, this voice should not utter another word, and therefore what would be the difference if you turned it off entirely?

        I would agree that it would be possible to write a script that would be vulnerable if taint-checking was disabled, but that would imply a faulty script and/or testing process (e.g. you never bothered to test the script using all available params)

        Once more with feeling - taint-checking doesn't make your data 'safe' - it just prevents your script from processing unsafe data. The mechanisms you place in your script to make data 'safe' will still be present irrespective of whether taint-checking is on or off

        Tom Melly, tom@tomandlu.co.uk