Bareword errors?

[Ben Morrow]

Yes, several years ago.


Sure.
http://groups.google.com/group/comp.lang.perl.misc/msg/d922a0fabe3ce436

OK, I can see there may be situations where that level of performance is
important. I still maintain it would be better practice to direct people
to a more efficient module if and when it becomes necessary, rather than
towards copy/pasting code.

Spurious? BS! By making such a claim, without presenting any proofs,
your credibility is eroded.

Note the 'almost certainly' . On the point of raw-speed-of-startup I
stand corrected. Whether this is the limiting factor in any one case
depends on what the CGI is doing, of course; I will believe you if you
say there are cases where it matters.

If this _really_ was about the value of code reuse via modules, why does
nobody object to e.g. this message:
http://groups.google.com/group/comp.lang.perl.misc/msg/1b4d3a3b268bf35c

I would have, in principle. Those two programs are (IMHO) nasty, and are
wrong in several particulars. They should be replaced with LWP.

In practice, I don't correct every piece of bad code that passes through
my newsreader: I simply don't have the energy. You may have noticed that
I am rarely one of those who jumps on people who aren't using CGI.pm, I
am merely defending what I see as good practice on behalf of those who
do.

Ben

 

[krakle]

There were also
big back and forths on the newsgroup by those more knowledgable than I
(that would be everyone) about the pluses and minuses of cgi.pm. I
haven't been burned *yet* by using the regexes and it's been in pretty
constant use for a while. I like to be able to control what is being
decoded for various reasons which I wasn't able to figure out in cgi.pm.
I've also fixed other peoples broken cgi's (again, linebreak issues) by
taking cgi.pm out and using regexes. YMMV.

What makes Perl so great is CPAN and all the available reliable
well-mantained quality modules.

Countless programmers have spent hours writing and mantaining module
code so we can have the capabilities to perform certain operations
trouble and stress free. This saves us from unneccessary development
time and headachs. You wouldn't spend hours and hours trying to
reinvent the wheel when the wheel is right infront of you ready to be
used.

What you have is a piece of code that dumps all parameters into Global
variables regardless of size. This will be stored in memory during the
duration of run time. Your sub form parsing technique is dated and
though may get the job done it also does ZERO error and safety handling
which makes it open to all sorts of future and present catastrophes.

You claim you want full control over how the form data is processed yet
you use it in the most generic way which makes your statement reflect
your inexperience even more so. If you have several CGIs and each use
the same copied sub-routine you are actually limiting functionality and
mantainability. Eventually you'd end up dumping the code in a module.
Then you will soon or later be forced into spending hours trying to
make your code more strict and bug free. Which would be reinventing the
wheel.

Modules are created for a reason. It's so programmers can use reliable
safe code instead of trying to reinvent the functionality of an
operation for every project. CGI.pm is the standard for parsing form
data if you choose not to use it you are only limiting yourself and
putting your web site, server and users at risk.

 

[Gunnar Hjalmarsson]

... it also does ZERO error and safety handling
which makes it open to all sorts of future and present catastrophes.

CGI.pm is the standard for parsing form
data if you choose not to use it you are only limiting yourself and
putting your web site, server and users at risk.

Another one who naively believes that using CGI.pm for parsing the input
makes a significant difference as regards security.

It does not.

 

[Gunnar Hjalmarsson]

Gunnar, why do you persist with that straw-man argument?

It's not straw-man, it's both true and significant.

Pointing out the
fact that CGI.pm securely parses CGI arguments does not imply a claim that
doing so is all that's needed to securely write CGI applications.

1. He didn't just claim that CGI.pm makes a difference as regards
security, he talked about "putting your web site, server and users at
risk" if you choose to not use it.

2. My objection above does not include the message you indicate.

3. Still, my belief is that using such arguments for advocating the use
of CGI.pm _does_ give the incorrect impression that you write
significantly more secure CGI programs only by using it.

This whole "skilled developers can improve upon CGI.pm, and shouldn't be
chastised for doing so" argument, while quite true, is irrelevant in this
case because is in fact *not* such a developer.

While I don't defend everything the OP in this thread said, neither do I
think that _anybody_ should be chastised for using a totally harmless
piece of code.

Point out the value of code reuse through modules, fine, that's good
advice. For god's sake, I'm also a module user (and author). I'm even
using CGI.pm from time to time.

But try to relax, and let it stay with that. Try to believe that the
readers of this group are grown-up people, who are capable of making
their own decisions on programming style.

 

[krakle]

3. Still, my belief is that using such arguments for advocating the use
of CGI.pm _does_ give the incorrect impression that you write
significantly more secure CGI programs only by using it.

Gunnar, would you agree that if a programmer chooses to parse his/her
own form data the algorithm he/she uses must be thorough, complete and
well tested for reliability?

If so, would you advocate against using an identical sub-routine copied
through out 10 CGI scripts? Programming with practical and logical
sense you'd recommend the programmer to create a module with his/her
thorough reliable code, right?

If so (once again), why would you waste time rewriting an existing
module if it meets HTTP standards if you're only going to use it in the
most generic form?

Would you really tell someone who is inexperienced (or even
experienced) to go a head and waste their time and their employers buck
producing some over the night immature code? I wouldn't hire you.

Even you yourself use CGI.pm. In Contact::Form (the module you are the
author of) you have:

# create hash reference to the form data
my $in = new CGI->Vars;

Interesting.

 

[Gunnar Hjalmarsson]

Gunnar, would you agree that if a programmer chooses to parse his/her
own form data the algorithm he/she uses must be thorough, complete and
well tested for reliability?

If so, would you advocate against using an identical sub-routine copied
through out 10 CGI scripts? Programming with practical and logical
sense you'd recommend the programmer to create a module with his/her
thorough reliable code, right?

If so (once again), why would you waste time rewriting an existing
module if it meets HTTP standards if you're only going to use it in the
most generic form?

Would you really tell someone who is inexperienced (or even
experienced) to go a head and waste their time and their employers buck
producing some over the night immature code? I wouldn't hire you.

Even you yourself use CGI.pm. In Contact::Form (the module you are the
author of) you have:

# create hash reference to the form data
my $in = new CGI->Vars;

Interesting.

I see nothing about security in your comments above. Good.

 

[Gunnar Hjalmarsson]

Quoth Gunnar Hjalmarsson:

OK, I can see there may be situations where that level of performance is
important. I still maintain it would be better practice to direct people
to a more efficient module if and when it becomes necessary, rather than
towards copy/pasting code.

If somebody asks "how do I parse CGI data?" I don't give him/her any
code, but rather point at the applicable FAQ entry. This situation was
slightly different...

Note the 'almost certainly' .

Hmm... Okay.

On the point of raw-speed-of-startup I
stand corrected. Whether this is the limiting factor in any one case
depends on what the CGI is doing, of course; I will believe you if you
say there are cases where it matters.

That's all I say. There are also a lot of cases where it doesn't matter.

 

[Ted Zlatanov]

On 3 Dec 2006, (e-mail address removed) wrote:

Another one who naively believes that using CGI.pm for parsing the
input makes a significant difference as regards security.

It does not.

While your argument is interesting on its own, note that krakle didn't
specifically point to security, and the risk he mentions in your quote
is actually the risk of downtime and bugs. Security is not mentioned
in the article he posted. I checked carefully--at least that's how I
read it, and I think most would agree with my reading.

Ted

 

[Gunnar Hjalmarsson]

While your argument is interesting on its own, note that krakle didn't
specifically point to security,

Note that not even krakle objected to my interpretation:
http://groups.google.com/group/comp.lang.perl.misc/msg/c09c0e267b8edf66

Anyway, as long as we are agreed that CGI.pm has little to do with
security, there is no point in speculating in what krakle actually meant.

 

[krakle]

Note that not evenkrakleobjected to my interpretation:http://groups.google.com/group/comp.lang.perl.misc/msg/c09c0e267b8edf66

Anyway, as long as we are agreed that CGI.pm has little to do with
security, there is no point in speculating in whatkrakleactually meant.

I didn't say anything about security. Since I referred ro CGI.pm's code
as "thorough, complete, and well tested for reliability" and the other
code as "limiting functionality and
mantainability" I didn't think I had to specify.

 

[krakle]

I see nothing about security in your comments above. Good.

Because I said nothing about security in my comments.

 

[Martijn Lievaart]

On 3 Dec 2006, (e-mail address removed) wrote:



While your argument is interesting on its own, note that krakle didn't
specifically point to security, and the risk he mentions in your quote
is actually the risk of downtime and bugs. Security is not mentioned
in the article he posted. I checked carefully--at least that's how I
read it, and I think most would agree with my reading.

Just as an aside, security typically consists of CIA, Confidentially,
Integrity, Availability. Somehow, people often only look at the C when
thinking about security. Downtime is A and is important from a security
stance (and can have C and I impact as well). Bugs can lead to breaches of
any of the catagories so are a scurity hazard as well.

Security is the science of managing risks due to unforseen errors. It
should always be a analysis of risks versus the cost of avoiding them. But
making this analysis can be very hard in some situations. However, one can
avoid some of this analysis by laying a baseline of contra measures.
Secure coding should always be one of those baselines. If you google on it
there are some guidelines for that on the net.

(Do note that security guidelines are hard to find in general, because
many companies make their money that way and are not going to put there
guidelines up for the public).

M4