[3484] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (John R Levine)
Thu Oct 15 17:36:51 1998
Date: Thu, 15 Oct 1998 17:07:26 -0400 (EDT)
From: John R Levine <johnl@iecc.com>
To: Matt Curtin <cmcurtin@interhack.net>
cc: cryptography@c2.net
In-Reply-To: <864st6auew.fsf@strangepork.interhack.net>
> One of the things that I've noticed about code that is error prone
> comes from inexpert use of the language in question. ...
> 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".
I agree, to the extent that I'm probably writing 95% perl and 5% C (that
entirely in patches and extensions to existing programs) these days. Like
any Real Programmer, I'm extremely lazy and Perl is far more productive.
Unfortunately, I think that an effect I observed 20 years ago in grad school
still applies: programmers will write the largest program they're able to,
given the tools they have. I looked at some of the AI applications that
people were writing in Lisp. They were large (for the time) and
sophisticated programs that those of us on the system side who had a lot more
programming experience would have had trouble doing in Bliss, C not yet
having arrived on the scene. But their code was garbage. Lisp let fairly
bad programmers get a lot farther before their programs fell over of their
own weight.
Given two equivalent programs in C and Perl, the Perl program will certainly
be a lot shorter and have a lot fewer bugs, both because Perl avoids whole
classes of errors, and because to a first approximation the number of bugs
per line of code is independent of the language. The Perl program may even
run faster, since it automatically takes advantage of high quality algorithms
for tasks like storage management, pattern matching, and hash tables which a
mediocre C programmer wouldn't use.
That's the good news. The bad news is that nobody writes equivalent programs
in C and Perl, except as an academic exercise. They write equivalent effort
programs, which means that the Perl program does a lot more than the C
program would, offering vast new vistas for algorithmic errors and
unanticipated interactions and side effects.
What's the implication for crypto and security here? There's no silver
bullet. The only way for systems to get more secure is for people to take
security more seriously. Sure, languages can help avoid some classes of
errors, and language features like assertions and pre- and post-conditions
can both help debugging and encourage programmers to think more clearly about
what their programs are supposed to do. But until we get past the mentality
of "it passed a 10 second smoke test, so ship it", we're going to be stuck
with the crudware that passes for programming today.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
