SPUG: Perl FUD
PFarrall at getthere.com
Tue Jul 25 16:42:31 CDT 2000
Thanks everyone for all your advice. I was already thinking of a lot of the
same technical points that were pointed out (Taint mode, no buffer
overflows, etc..), but it was reassuring to see my thoughts mirrored and I
got a few ideas I hadn't thought of too.
The advice on how to approach the discussion (aka politics) was especially
useful and I now have a list of bulleted points that I can respond with.
Hopefully this will direct the discussion away from blanket statements like
"C Good. Perl Bad" and towards specific concerns and issues.
> -----Original Message-----
> From: lorraine at nw.saic.com [mailto:lorraine at nw.saic.com]
> Sent: Tuesday, July 25, 2000 12:54 PM
> To: Paul Farrall; 'spug-list at pm.org'
> Subject: Re: SPUG: Perl FUD
> From my reading, it seems that no language can be considered
> fool-proof and
> safe. (If there WERE such a language, everyone would have
> abandoned C/C++,
> Java, and Perl for CGI programs long ago.) The point is to
> understand the
> common mistakes for your language which can lead to security holes and
> develop a checklist for catching them. For example, in C,
> string variables
> have declared lengths, so you need to check that the user
> hasn't entered
> more than that number of characters - a buffer overflow.
> (And you need to
> remember that the end of string marker counts in the number
> of characters!)
> On the plus side for Perl, there's taint mode, where you are
> warned if you
> try to use user-supplied data without validating it. Since Perl is so
> heavily used on the Internet, I would think its pitfalls are
> pretty well
> known by now. There are a number of resources on avoiding
> insecure Perl
> (I've found help for my CGI work at http://advosys.ca, there's CERT,
> http://www.w3.org/Security/Faq/www-security-faq.html). If
> not developing for the Web, then some of that information
> doesn't apply,
> but much of it is general.
> To sum up, any language will have it's security traps.
> Perl's advantages
> are that: it has an automatic checking mode which HELPS you
> avoid them; it
> is well-supported by multiple resources (print, Web, human);
> and its user
> community will openly discuss problems and work-arounds.
> Hope this is useful,
> At 10:48 AM 7/25/00 -0700, Paul Farrall wrote:
> >At the Perl Conference Town Meeting, someone got up and said; "Perl
> >has a serious image problem, what can we do to address
> this?". At the
> >time, I thought wow it must suck to work at a place where the bosses
> >buy into all the Perl FUD strewn about. Foolish me........
> >When I got back to work on Monday, I sent a summary of the conference
> >to my department and the following reply came back from the VP of
> >> Given security issues, is it a good idea to be using PERL for our
> >> tools?
> >Does anyone have any good advice on how to respond to this? Keep in
> >mind that this guy is my boss :-).
> >Paul Farrall
> J. Lorraine Johnson
> SAIC/Sea Technology
> lorraine at nw.saic.com
> v: (425) 482-3316
> f: (425) 485-5566
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - -
> POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
> Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
> Replace ACTION by subscribe or unsubscribe, EMAIL by your
> For full traffic, use spug-list for LIST ; otherwise use
> Seattle Perl Users Group (SPUG) Home Page:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
More information about the spug-list