Clearing sensitive in-memory data in perl
John Gilmore
gnu at toad.com
Fri Sep 16 21:39:38 EDT 2005
> >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
More information about the cryptography
mailing list