Great Circle Associates List-Managers
(October 1999)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Sympa? mailman?
From: Nick Simicich <njs @ scifi . squawk . com>
Date: Tue, 12 Oct 1999 02:25:57 -0400
To: Jeremy Blackman <loki @ maison-otaku . net>
Cc: list-managers @ GreatCircle . COM
In-reply-to: <Pine . LNX . 4 . 10 . 9910112250140 . 9766-100000 @ godai . maison-otaku .net>
References: <3 . 0 . 5 . 32 . 19991011215753 . 03622220 @ 127 . 0 . 0 . 1>

At 10:57 PM 10/11/99 -0700, Jeremy Blackman wrote:
>In his case, what was largely the problem was that his Perl was
>misconfigured and was trying to parse through a GREAT many more Perl
>libraries than was needed.  Each invokation of resend took about 5
>_minutes_.  Believe me, I helped track down and fix the
> IS possible to do that.  It is much HARDER to do
>something like that (misconfigure in such a way) under C.

No, in C, you will write something casual and a cracker will figure out how
to cause a buffer overflow and wrest control of your system away from you
over a distance :-).

Being a security geek, I far prefer it when clients write programs in
intermediate level scripting languages such as perl.  Sorry, but the
average C or C++ programmer can't handle the concept of safely flattening
an object into a structure, or even reading a string from an external
source.  Any language with self sizing strings is a tremendous improvement,
security wise.

However, there are pathological cases of this sort all of the time.  Five
minutes to invoke a Perl script?  I'd call that pathological and probably
not worth considering as part of an evaluation.  I'd also not blame the
scripting language for a configuration that bad.

>You are, however, correct that sendmail did not aid the situation.
>I will also admit I am biased against writing applications in scripting
>languages as a general rule, because I've seen some things done very, very
>wrong in them.  I've seen some things done wrong in C as well, and I've
>seen some things done right in scripting languages, but as a general rule
>for some reason I feel more like daemons and such should be written in C
>or C++ or SOMETHING that compiles and produces a binary.

>From a security standpoint, I think you've been proven wrong over and over

>When I see things on freshmeat like 'HTTP Daemon written in Perl' or 'MTA
>written in Perl' or 'FTP client written in shell scripting language', I
>just want to run screaming and hide under my desk. :)

Sometimes things are done as interesting exercises, like the (very old)
attempt to prove that vi was as "powerful" as emacs by writing a turing
machine in vi.  But sometimes things are reasonable to do.  I still assert
that the scriptable portion of MLM's structured like majordomo is not only
both reasonable, but more likely to be extensible and secure than the
equivalent C Code.

The general rule of thumb I've used before is that if it was possible to
easily enumerate the number of times something was going to happen through
circumstance, it was reasonable to write a script to do it.  If it was hard
to enumerate but still driven by circumstance, it was probably OK to write
in an object oriented language.  If it was damn near impossible to
enumerate because it happened so often or extremely easy to enumerate
because it happened on a continuous basis, it probably had to be in C or
assembler, with no objects.

>> Cows With Guns
>Good song. :)

It is a song?  I can hear the gunfire from my windows now..
If we aren't supposed to eat animals, why are they made of meat?
Nick Simicich mailto:njs @
 scifi .
 squawk .
 com -- Stop by and Light Up The World!

Indexed By Date Previous: Re: Sympa? mailman?
From: Jeremy Blackman <loki @ maison-otaku . net>
Next: Re: now blocking mail from (fwd)
From: Jeffrey Goldberg <J . Goldberg @ Cranfield . ac . uk>
Indexed By Thread Previous: Re: Sympa? mailman?
From: Chuq Von Rospach <chuqui @ plaidworks . com>
Next: Re: Sympa? mailman?
From: Aumont - Comite Reseaux des Universites <Serge . Aumont @ cru . fr>

Search Internet Search