Clearing sensitive in-memory data in perl

[John Gilmore]

> >Generally speaking, I think software with a security impact should not
> >be written in C.

Hooey.

The C language is not the problem.  The C library is not the problem.
Both of these things were fixed during ANSI standardization, so that
standard-conforming programs will not fail runtime checks for
overrunning arrays (strings are just arrays of characters).

There have been various C implementations that did these checks,
including both compilers and interpreters.  Some are free, some are
proprietary.  (I proposed to fund adding these checks to GCC, but the
price I was quoted was too high for me.)  I fault the people who don't
use such tools -- not the C language.

(Aside: What ever happened to Saber C?  Oh, it was renamed to
Centerline CodeCenter, never made it out of the Unix workstation
market, used "FlexLM" per-cpu licensing crap, has gone morbid, and was
acquired a year ago by ICS.com, a graphics library company, with a
promise to port it to Linux.  There's no evidence of such a port, and
the "product support matrix" was last updated in June 2001.  The
product doesn't appear on ICS's product pages.  I wonder how cheaply
the source could be bought and freed up, to bring it back to life?  It
was a nice product, fifteen years ago.)

The reason there's fewer security bugs in PL/1 programs than C
programs is because almost nobody has written programs in PL/1 since
about 1985.  Google did find me a compiler you can download -- it runs
on VMS, on Vaxes or Alphas.  Anybody still running those space-heaters
is welcome to program in PL/1.  The rest of us have real work to do,
and it's likely to get done in C or C++.

	John


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com