[3483] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (Matt Curtin)
Thu Oct 15 16:18:47 1998
To: perry@piermont.com
Cc: Phil Karn <karn@qualcomm.com>, cryptography@c2.net
From: Matt Curtin <cmcurtin@interhack.net>
Date: 15 Oct 1998 08:20:23 -0400
In-Reply-To: "Perry E. Metzger"'s message of "Wed, 14 Oct 1998 22:00:00 -0400"
"Perry E. Metzger" <perry@piermont.com> writes:
> In the long run, though, the only solid solution is using a superior
> language, like Java, for tasks that aren't extremely time critical.
One of the things that I've noticed about code that is error prone
comes from inexpert use of the language in question. While lower
level languages like C and assembly make it easy to introduce security
(and other) bugs, these are typically in ways that are unrelated to
the software being developed. Blown buffers, memory management
problems, etc.
Using the likes of Java, Perl, and Lisp will go a long way to
eliminate that class of problems. And everyone who has participated
in this thread knows that there is no Silver Bullet which will solve
all of our problems.
It will be helpful to get beyond C in userland, and I think it's a
goal worth pursuing. Don't get me wrong--C has been a Good Thing, but
it's important to recognize what C is good at doing and where it is
weak. C isn't good for everything, but it is good for jobs that used
to be done in assembler. Kernels are good candidates for C
implementations.
The last year or two, I've been a big proponent of using higher level
(than C) languages for "most" tasks, in fact, anything that could be
called an "application".
In pursuing this, though, we need to be careful that we're not
allowing ourselves to do *other* dumb things. It's still possible to
screw up our algorithms, our protocols, and whatnot. We're still
going to have to be careful and inspect each others' work.
--
Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/
