Home > Archive > PERL Miscellaneous > May 2005 > FormMail Problem
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Olen R. Pearson 2005-05-23, 8:56 pm |
| Hi,
I am using FormMail.CGI v. 1.92 (04/21/02) to process s form on a Website.
Though I am not familiar with Perl, I have used this script and its earlier
versions for several years without problems.
Now, the script will process the form for some e-mail addresses but not
others, giving the error message:
Error: Bad/No Recipient
There was no recipient or an invalid recipient specified in the data sent to
FormMail. Please make sure you have filled in the recipient form field with
an e-mail address that has been configured in @recipients.
Here are the pertinent lines from the script:
@referers = ('nursesaregreat.com','fast.net','citcom.net','verizon.net');
@recipients = &fill_recipients(@referers);
and from the form code
<input type=hidden name="recipient" value="louiseandroy@verizon.net">
It seems to work for email addresses at 'nursesaregreat.com', 'fast.net',
and 'citcom.net' but NOT 'veerizon.net'.
Any ideas??
Thanks.c
| |
| Gunnar Hjalmarsson 2005-05-23, 8:56 pm |
| Olen R. Pearson wrote:
> I am using FormMail.CGI v. 1.92 (04/21/02) to process s form on a Website.
> Though I am not familiar with Perl,
Please note that this group is for discussing Perl programming matters,
not for providing help to use particular scripts.
> Now, the script will process the form for some e-mail addresses but not
> others, giving the error message:
>
> Error: Bad/No Recipient
> ...
<snip>
> Any ideas??
Ask the script author for assistance.
If you don't get help that way (you probably don't...), try one of the
form-to-mail solutions at http://nms-cgi.sourceforge.net/scripts.shtml
instead.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Christopher Nehren 2005-05-23, 8:56 pm |
| On 2005-05-23, Gunnar Hjalmarsson scribbled these
curious markings:
> Olen R. Pearson wrote:
> If you don't get help that way (you probably don't...), try one of the
> form-to-mail solutions at http://nms-cgi.sourceforge.net/scripts.shtml
> instead.
Even if you *do* get help that way, *stop* using FormMail now. It's
horribly, horrendously insecure and thoroughly broken.
Best Regards,
Christopher Nehren
--
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
If you ask the wrong people questions, you get "Joel on Software".
Unix is user friendly. However, it isn't idiot friendly.
| |
| Gunnar Hjalmarsson 2005-05-24, 3:56 am |
| Christopher Nehren wrote:
>
> *stop* using FormMail now. It's
> horribly, horrendously insecure and thoroughly broken.
Even if I'm not sure, I have a feeling that you are referring to
previous versions. If also v. 1.92 deserves that verdict, it would be
nice if you (or somebody else) could explain *how* it's broken.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-24, 3:58 pm |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> Christopher Nehren wrote:
>
> Even if I'm not sure, I have a feeling that you are referring to
> previous versions. If also v. 1.92 deserves that verdict, it would be
> nice if you (or somebody else) could explain *how* it's broken.
I don't know about security but it's still substandard Perl code.
I see no strict, no warnings, use of global package variables all over
the place and a general lack of familiarity with Perl's possiblilities.
Some use of qr() would help the code as would POSIX::strftime instead
of the homebrew date conversion.
One concrete example (there are more):
$Config{'required'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
$Config{'required'} =~ s/(\s+)?\n+(\s+)?//g;
$Config{'env_report'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
$Config{'env_report'} =~ s/(\s+)?\n+(\s+)?//g;
$Config{'print_config'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
$Config{'print_config'} =~ s/(\s+)?\n+(\s+)?//g;
That should be something like (untested):
for ( @config{ qw( required env_report print_config} ) {
s/(\s+|\n)?,(\s+|\n)?/,/g;
s/(\s+)?\n+(\s+)?//g;
}
As mentioned I didn't look for holes (other people are presumably
doing that), but the coding standard doesn't instil much confidence.
The vulnerabilities that have been exposed in the past may have been
fixed, but a secure program must be written with security in mind
from the start. Clearly this code hasn't seen a ground-up rewrite
since its beginnings under Perl 4. I wouldn't trust it.
Anno
| |
| Gunnar Hjalmarsson 2005-05-24, 3:58 pm |
| Anno Siegel wrote:
> Gunnar Hjalmarsson wrote:
>
> I don't know about security but it's still substandard Perl code.
I do of course not suggest that it's good code in the light of today's
standards. Not even the author does, btw.
> I see no strict, no warnings, use of global package variables all over
> the place and a general lack of familiarity with Perl's possiblilities.
> Some use of qr() would help the code as would POSIX::strftime instead
> of the homebrew date conversion.
>
> One concrete example (there are more):
>
> $Config{'required'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
> $Config{'required'} =~ s/(\s+)?\n+(\s+)?//g;
> $Config{'env_report'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
> $Config{'env_report'} =~ s/(\s+)?\n+(\s+)?//g;
> $Config{'print_config'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
> $Config{'print_config'} =~ s/(\s+)?\n+(\s+)?//g;
>
> That should be something like (untested):
>
> for ( @config{ qw( required env_report print_config} ) {
> s/(\s+|\n)?,(\s+|\n)?/,/g;
> s/(\s+)?\n+(\s+)?//g;
> }
Okay. But broken? Not just broken, but *thoroughly broken*?
> As mentioned I didn't look for holes (other people are presumably
> doing that),
I'm waiting. :)
> Clearly this code hasn't seen a ground-up rewrite
> since its beginnings under Perl 4.
There were two points I tried to raise by replying to Christopher's post:
1. Perl 4 style programs are not automatically *broken*.
2. When somebody claims that one of the most spread Perl scripts out
there is "horribly, horrendously insecure and thoroughly broken", it's
reasonble to demand that he provides evidence supporting the statement.
If he doesn't, maybe even can't, the claim tells me more about the
judgement of the one who makes the claim than about the code in question.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-24, 8:56 pm |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
[color=darkred]
[...]
[color=darkred]
> There were two points I tried to raise by replying to Christopher's post:
>
> 1. Perl 4 style programs are not automatically *broken*.
Not my point. I mention the Perl 4 style to show that the program
has not been re-written since its Perl 4 days, when it *was* broken.
> 2. When somebody claims that one of the most spread Perl scripts out
> there is "horribly, horrendously insecure and thoroughly broken", it's
> reasonble to demand that he provides evidence supporting the statement.
> If he doesn't, maybe even can't, the claim tells me more about the
> judgement of the one who makes the claim than about the code in question.
Probably the wording doesn't apply to the current code anymore. (I wasn't
aware of the update myself.) However it must still be considered insecure
because it wasn't designed for security (provably), and hasn't been
redesigned. So these days it's bad Perl, derived from horribly insecure
Perl. I'd still not recommend it :)
Anno
| |
| Damian James 2005-05-24, 8:56 pm |
| On 24 May 2005 22:40:45 GMT, Anno Siegel said:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> [...]
>
> Not my point. I mention the Perl 4 style to show that the program
> has not been re-written since its Perl 4 days, when it *was* broken.
>
>
> Probably the wording doesn't apply to the current code anymore. (I wasn't
> aware of the update myself.) However it must still be considered insecure
> because it wasn't designed for security (provably), and hasn't been
> redesigned. So these days it's bad Perl, derived from horribly insecure
> Perl. I'd still not recommend it :)
I am baffled slightly that there's been an ongoing discussion of one
of MW's old broken cgi scripts here without mention being made of the
NMS project. I did have the understanding that there are versions of
"FormMail.cgi" there that one ought to be able to recommend to neophytes
with moderate confidence...
Google took me to: http://nms-cgi.sourceforge.net/scripts.shtml
Hope that's of some help to the OP. I'd strongly implore that he not use
any extant original Formmail script without at least looking at the much
better versions available.
--damian
| |
| Gunnar Hjalmarsson 2005-05-25, 3:58 am |
| Damian James wrote:
> I am baffled slightly that there's been an ongoing discussion of one
> of MW's old broken cgi scripts here
The discussion has been about whether it's accurate to describe version
1.92 of Matt's FormMail script as "horribly, horrendously insecure and
thoroughly broken" without providing any evidence. I notice that also
you refer to it as "broken", but that does not make a more accurate
description just because it's being repeated, does it?
> without mention being made of the NMS project.
NMS was mentioned.
> I did have the understanding that there are versions of
> "FormMail.cgi" there that one ought to be able to recommend to neophytes
> with moderate confidence...
>
> Google took me to: http://nms-cgi.sourceforge.net/scripts.shtml
You could have viewed my first reply in this thread instead:
http://groups-beta.google.com/group...8b264fe6eb8bec8
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Eric Schwartz 2005-05-25, 3:58 am |
| Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Damian James wrote:
>
> The discussion has been about whether it's accurate to describe
> version 1.92 of Matt's FormMail script as "horribly, horrendously
> insecure and thoroughly broken" without providing any evidence.
Here's some evidence: without getting into whether or not it's a good
idea to write your own CGI-parsing code, the CGI-parsing code in there
doesn't catch a few of the most common error cases (query string
delimited by ; not & for GET, and read not reading all data in the
buffer at once for POST). That qualifies, to me, as broken, at
least. Also, the regex for valid emails will flag as failed a number
of valid addresses.
As for security holes, there's the obvious one that HTTP_REFERER is
easily spoofable. If you're paying attention, you can restrict
somewhat the domains to which a DDOS can be directed, but it's next to
impossible to use without opening yourself up to one.
There's also a lot of ugly syntax and bad coding practises in there
I'd hate to see anybody emulate-- every function is called with
leading &, the whole get_date routine would be better off as
appropriate calls to POSIX::strftime().
So yeah, on further study I'd agree that 'broken' and 'insecure' are
empirically valid adjectives. You may disagree with the adverbs, if
you like; those are clearly value judgements.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
| |
| Christopher Nehren 2005-05-25, 3:58 am |
| On 2005-05-23, Gunnar Hjalmarsson scribbled these
curious markings:
> Even if I'm not sure, I have a feeling that you are referring to
> previous versions. If also v. 1.92 deserves that verdict, it would be
> nice if you (or somebody else) could explain *how* it's broken.
First, no taint checking. Sure, this in itself doesn't make the code
insecure, but it's certainly not helping things.
The lack of 'use CGI;', while similarly not instantly insecure, bothers
me in a similar fashion. Okay, it was written in the days of Perl 4, but
that's no reason that it couldn't have been updated.
I wouldn't rely on something like /usr/lib/sendmail (and realistically
couldn't, if taint checking were enabled), and would opt to go with
a module. This would give one portability in most cases as well as
security (assuming no external program is used).
In &parse_form, the /e operator to s/// is applied on completely
unprocessed CGI variables -- not once, but twice. I don't even want to
think about what that can cause.
Best Regards,
Christopher Nehren
--
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
If you ask the wrong people questions, you get "Joel on Software".
Unix is user friendly. However, it isn't idiot friendly.
| |
| Sherm Pendley 2005-05-25, 3:58 am |
| Christopher Nehren wrote:
> The lack of 'use CGI;', while similarly not instantly insecure, bothers
> me in a similar fashion. Okay, it was written in the days of Perl 4
A weak excuse at best - Perl 4 may not have had CGI.pm, but it *did*
have cgi-lib.pl.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
| |
| Damian James 2005-05-25, 3:58 am |
| On Wed, 25 May 2005 02:42:54 +0200, Gunnar Hjalmarsson said:
> Damian James wrote:
>
> The discussion has been about whether it's accurate to describe version
> 1.92 of Matt's FormMail script as "horribly, horrendously insecure and
> thoroughly broken" without providing any evidence. I notice that also
> you refer to it as "broken", but that does not make a more accurate
> description just because it's being repeated, does it?
I am amazes that you consider it worth anyone's time to do that. It has been
done, and done many, many times. Perhaps not in this thread but over several
years in this newgroup, quite possibly hundreds of times. I refuse to be
specific or enumerate that, and insist that it is worth noone's time to do so
again, and again, and again. Search the archives, for goodness' sake.
> ...
> You could have viewed my first reply in this thread instead:
> http://groups-beta.google.com/group...8b264fe6eb8bec8
>
Fine. Glad to see that someone had the sense to point that out. Given that
an example of a known-good version of the program exists, why is this being
discussed at all? Move on. Next!
;)
--damian
| |
| Gunnar Hjalmarsson 2005-05-25, 8:56 pm |
| Eric Schwartz wrote:
> Gunnar Hjalmarsson writes:
>
> the CGI-parsing code in there
> query string delimited by ; not & for GET,
It's a *form*-to-mail script, so ';' as delimiter is not applicable.
=> Not broken.
> and read not reading all data in the buffer at once for POST
Well, it normally does its work as intended...
> Also, the regex for valid emails will flag as failed a number
> of valid addresses.
True.
> As for security holes, there's the obvious one that HTTP_REFERER is
> easily spoofable.
<quote from the FormMail docs>
This is not a security check. Referer headers can EASILY be faked.
</quote from the FormMail docs>
=> Not a security hole.
> So yeah, on further study I'd agree that 'broken' and 'insecure' are
> empirically valid adjectives. You may disagree with the adverbs, if
> you like;
I do. It was them that caused me to object.
> those are clearly value judgements.
So are the adjectives, to some extent. For a serious and accurate
discussion on programming code, you'd better be careful about which
"value judgements" you use. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Gunnar Hjalmarsson 2005-05-25, 8:56 pm |
| Christopher Nehren wrote:
> On 2005-05-23, Gunnar Hjalmarsson scribbled these
> curious markings:
>
> First, no taint checking. Sure, this in itself doesn't make the code
> insecure,
Probably not in this particular script. And certainly not "horribly,
horrendously insecure".
> The lack of 'use CGI;', while similarly not instantly insecure,
True.
> I wouldn't rely on something like /usr/lib/sendmail (and realistically
> couldn't, if taint checking were enabled),
Are you saying that you can't open a pipe to a program when tainted mode
is enabled? That is simply not correct.
> In &parse_form, the /e operator to s/// is applied on completely
> unprocessed CGI variables -- not once, but twice.
Are you talking about
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
etc.? Note that the /e modifier is applied on the right side of the s///
operator, not the $value variable.
> I don't even want to think about what that can cause.
I do recommend that you think about it.
So, is that all there is? I'm stunned.
You'd better be more careful of how you express yourself, man. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Eric Schwartz 2005-05-26, 3:57 am |
| Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Eric Schwartz wrote:
>
> It's a *form*-to-mail script, so ';' as delimiter is not applicable.
UAs can split up the args however they like. Still broken.
>
> Well, it normally does its work as intended...
Normally most things do, so why should we bother testing anything for
failure? That's poor reasoning if ever I saw it.
>
> <quote from the FormMail docs>
> This is not a security check. Referer headers can EASILY be faked.
> </quote from the FormMail docs>
>
> => Not a security hole.
Just because the docs alert you to it doesn't mean it's not a hole.
All it means is that the author is aware of the hole. Also, someone
else pointed out the /e on the regexes, which I didn't notice.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
| |
| Gunnar Hjalmarsson 2005-05-26, 3:57 am |
| Eric Schwartz wrote:
> Gunnar Hjalmarsson writes:
>
> UAs can split up the args however they like. Still broken.
No browser will use anything but '&' in the foreseeable future.
>
> Normally most things do, so why should we bother testing anything for
> failure? That's poor reasoning if ever I saw it.
Okay, I admit that. :)
>
> Just because the docs alert you to it doesn't mean it's not a hole.
How can a feature that is not intended to provide for security be a
security hole??
> Also, someone else pointed out the /e on the regexes, which I
> didn't notice.
What about it? Did you read my reply?
http://groups-beta.google.com/group...81511a4fc69d112
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-26, 3:57 am |
| Eric Schwartz <emschwar@pobox.com> wrote in comp.lang.perl.misc:
> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
[...]
[color=darkred]
> Also, someone
> else pointed out the /e on the regexes, which I didn't notice.
Those are harmless (much as I'd like to find fault with FormMail :)
A substitution "s/xxx/$user_string/e" is not like "eval $user_string"
but similar to "eval qq( $user_string)". That doesn't interpret
$user_string.
s///ee is another matter.
Anno
| |
| Gunnar Hjalmarsson 2005-05-26, 3:58 pm |
| Anno Siegel wrote:
> much as I'd like to find fault with FormMail :)
Not only you.
And that explains this unnecessary thread just because I pointed out
that "horribly, horrendously insecure and thoroughly broken" is not an
accurate description of the script the OP asked for help with. :(
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-26, 3:59 pm |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
>
> Not only you.
>
> And that explains this unnecessary thread just because I pointed out
> that "horribly, horrendously insecure and thoroughly broken" is not an
> accurate description of the script the OP asked for help with. :(
You seem to take this as inexplicable random hostility, but there's
a history to it. Matt (personally quite the nice guy, it seems) has,
over many years, ignored pleas from the Perl community to take down,
fix, or get help fixing his archives. That may be understandable from
a young programmer whose crappy programs have hit the market successfully,
(and they were unmitigated crap in the beginning) but the net effect
was a drain of effort from the rest of the community. That isn't taken
lightly, and it is no wonder the efforts at fixing the scripts is seen
as "too little too late".
Anno
| |
| Gunnar Hjalmarsson 2005-05-26, 3:59 pm |
| Anno Siegel wrote:
> Gunnar Hjalmarsson wrote:
>
> You seem to take this as inexplicable random hostility,
Hostility: yes, inexplicable or random: no.
> but there's a history to it.
I know *that* there is a history to it, even if I don't know (or care)
about the details.
What I think you and other 'gurus' should consider is that many
beginners don't know anything about those disagreements from almost 10
years ago. Accordingly, comments such as the above don't serve any
useful purpose. Instead they may cause confusion and hurt the
credibility of the regulars here, preventing beginners from listening
when you want to say something really important.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-26, 3:59 pm |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
[mostly snipped]
[color=darkred]
> What I think you and other 'gurus' should consider is that many
> beginners don't know anything about those disagreements from almost 10
> years ago. Accordingly, comments such as the above don't serve any
> useful purpose.
The purpose is to dissuade people from using the substandard Perl coming
from Matt's archives to this day, running it or more importantly imitating
it. That's reason enough for me.
Anno
| |
| Gunnar Hjalmarsson 2005-05-26, 9:00 pm |
| Anno Siegel wrote:
> Gunnar Hjalmarsson wrote:
>
> The purpose is to dissuade people from using the substandard Perl coming
> from Matt's archives to this day, running it or more importantly imitating
> it. That's reason enough for me.
Then call their attention to the fact that there are more up-to-date and
better alternatives to Matt's scripts at
http://nms-cgi.sourceforge.net/scripts.shtml
That's all there needs. Simple, accurate and credible.
It's high time that the Perl community gets cured from the Matt Wright
phobia. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Tad McClellan 2005-05-27, 4:00 am |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Anno Siegel wrote:
I have noted several such unnecessary threads that you've originated.
Everybody gets to post whatever they want to say, "necessity"
does not come into it.
One person is free to call it crappy code.
Another person is free to call it merely brown and smelly,,
pointing out that that isn't truly "crappy".
And off we go...
[color=darkred]
>
> Hostility: yes, inexplicable or random: no.
>
>
> I know *that* there is a history to it, even if I don't know (or care)
> about the details.
>
> What I think you and other 'gurus' should consider is that many
> beginners don't know anything about those disagreements from almost 10
> years ago.
They don't need to, if the code is crappy whenever it is that
they see it.
> Accordingly, comments such as the above don't serve any
> useful purpose.
Crappy code is crappy code, whether it is the original crappy
code or a revision of the crappy code.
Saying so serves a great purpose to beginners who, by definition,
don't know enough to recognize what code is crappy.
> Instead they may cause confusion and hurt the
> credibility of the regulars here,
A beginners choice of Sensei has a powerful bearing on how
close to mastery they can become. There are good choices,
and not so good choices.
> preventing beginners from listening
> when you want to say something really important.
Telling them to NOT learn from crappy example code *is* really important.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
| |
| Gunnar Hjalmarsson 2005-05-27, 8:56 am |
| Tad McClellan wrote:
> Gunnar Hjalmarsson wrote:
>
> I have noted several such unnecessary threads that you've originated.
Really? Wonder who is the originator this time.
The person who posts a gross exaggeration?
Those who try to defend that exaggeration?
Me who object to the exaggeration?
It's obvious from Christopher's follow-up that he doesn't know enough
Perl to express such a depreciatory opinion on someone else's code, and
that his opinion is merely hearsay.
Defending such a conduct is not a wise thing to do.
There is a fairy tale for kids about the peril of repeated, unwarranted
warnings which is applicable to this discussion. Unfortunately I don't
know its name...
> Telling them to NOT learn from crappy example code *is* really important.
s/telling/convincing/
That replacement makes the meaning of the sentence significantly
different. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
|
|
|
|
| Tad McClellan 2005-05-27, 4:00 pm |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Tad McClellan wrote:
[color=darkred]
> It's obvious from Christopher's follow-up that he doesn't know enough
> Perl
I didn't see anything in his followup that indicated a skill level.
I must have missed the obvious, what was it that you saw?
> to express such a depreciatory opinion on someone else's code, and
> that his opinion is merely hearsay.
>
> Defending such a conduct is not a wise thing to do.
I could agree with that IF it be could established as hearsay.
> There is a fairy tale for kids about the peril of repeated, unwarranted
> warnings which is applicable to this discussion. Unfortunately I don't
> know its name...
You are probably thinking of "The Boy Who Cried Wolf".
I'd have to disagree that warning people off of crappy code
is "unwarranted" though.
>
> s/telling/convincing/
>
> That replacement makes the meaning of the sentence significantly
> different. ;-)
You are right, that would be better, but it would take much longer.
When faced with choosing from:
1) convincing them at the expense of many followups or much time.
2) telling them at the expense of about 20 seconds.
3) saying nothing and letting them learn the hard way.
those pressed for time might be more soft-hearted than simply
going with #3. :-)
Most particularly when they have already participated in a dozen
or so previous #1-ish iterations (ie. they've done their time).
Mom often tells me to "look both ways before crossing the street".
She will, of course, explain why if I ask. But after a couple of
rounds of her explaining and me forgetting, she's likely to
revert to simply telling me once again.
Keeping me from getting hit by a bus is "warranted" from
my point of view, I like being around. :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
| |
| Gunnar Hjalmarsson 2005-05-29, 3:58 am |
| Tad McClellan wrote:
> Gunnar Hjalmarsson wrote:
>
> I didn't see anything in his followup that indicated a skill level.
>
> I must have missed the obvious, what was it that you saw?
Unlike what Christopher stated
1) pipes to other programs can be opened also when taint mode is
enabled, and
2) the /e modifier in the expressions for unescaping URI escaped strings
s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
isn't dangerous.
To me, that indicates a limited skill level (which isn't a 'crime' in
itself...). Anyway, considering that, and since Christopher's other
comments are far from supporting his depreciatory opinion on FormMail,
the logical conclusion is that the opinion is merely hearsay.
It's funny. Normally, such incorrect statements on Perl would have
resulted in several correcting follow-ups. Now, since they were made
with the aim of discrediting FormMail, that did not happen.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Anno Siegel 2005-05-29, 8:57 am |
| Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in comp.lang.perl.misc:
> Tad McClellan wrote:
[...]
[color=darkred]
> Unlike what Christopher stated
>
> 1) pipes to other programs can be opened also when taint mode is
> enabled, and
>
> 2) the /e modifier in the expressions for unescaping URI escaped strings
>
> s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>
> isn't dangerous.
[...]
> It's funny. Normally, such incorrect statements on Perl would have
> resulted in several correcting follow-ups. Now, since they were made
> with the aim of discrediting FormMail, that did not happen.
Both have been pointed out in this thread befor now.
Anno
| |
| Gunnar Hjalmarsson 2005-05-29, 8:57 am |
| Anno Siegel wrote:
> Gunnar Hjalmarsson wrote:
>
> [...]
>
>
> Both have been pointed out in this thread befor now.
Yeah, by me. And you commented on the /e modifier, even if it was in a
reply to Eric...
Maybe I shouldn't have said that. Probably not. :)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
|
|
|
|
|