note
strfry()
<p>i agree wholeheartedly (especially about it not being off-topic); we've all seen how perfectly capable Perl is as a programming language - and that itself
has a few caveats, if a user doesn't know what they're doing when they make their favorite script suid root. While I know this is a very basic example, it still stands that
some of us (IMHO all of us) could benefit from <b>more</b> talk of ways to keep Perl scripts and applications secure. As far as I've seen, Perl/Apache (be it mod_perl or vanilla CGI) is the
most common CGI language/server combination on the web (well, according to apache - they've got a figure of around 56% floating on their website)</p>
<p>and users would do well to remember what happens when Quick and Easy programs don't stay quick and easy. Sometimes, they'll actually be used by other people, and built upon... maybe even be the basis of more widely used applications. Eventually, with poor design, and a little rum involved, they sometimes grow to be a web-based SNAFU <tt><code>[tm]</code></tt> of incredible size. <br>
(where i work, when we integrate our software with other companies e-commerce solutions, it's frightening how often I see 'unpatched' formmail.pl / formmail.cgi in their cgi-bins!)</p>
<p> in a nutshell, i feel pretty darn lucky to be able to code in something that keeps track of it's own memory, doesn't require me to do type definitions, and gives me simple, intelligent ways to handle text; Perl is great if you're lazy. but it won't keep you from falling on your face if you don't watch where you put your feet.
<br>in a smaller nutshell, <code>use strict;</code>, <code>use warnings;</code>, use the <code> -T</code> switch, and watch your step. (:</p>
--<br>Peace,<br>[strfry{}]
129470
129481