I think the discussion regarding the thread
Re: [SC-L] Education and security -- another perspective
(was "ACM Queue - Content")
is in part becoming a debate of language X vs language Y. Instead,
I'd like to take this thread off into another direction (if Ken
thinks it's appropriate to the charter of this list). [Perhaps,
this has been discussed before here or elsewhere. A quick Google
search revealed a thread in SecurityFocus 'Security Basics'
mailing list that didn't contain much in the way of substance.]
[Ed. Concur, and I was rapidly approaching the point of asking the thread
to die or go elsewhere. The pros and cons of a particular language's
strength in an academic curriculum are interesting, however --
particularly when it comes to issues re teaching students secure coding
practices. KRvW]
Anyway, here's my question...
If a GENERAL PURPOSE programming language were designed by
scratch by someone who was both a security expert and
programming language expert, what would this language (and
it's environment) look like?
More specifically,
+ What set of features MUST such a language support (e.g.,
strong static typing, etc.)?
+ Perhaps just as importantly, what set of features should
the language omit (e.g., pointer arithmetic, etc.)?
+ What functionality should the accompanying libraries support
(e.g., encryption, access control, etc.)?
+ What would be the optimal paradigm (from a theoretical, rather
than pragmatic perspective) that such a language would fit into
(e.g., object-oriented, functional, imperative, logic programming,
etc.)? [Note: I mention "theoretical, rather than pragmatic" so
that such a language would be unduly influenced by the fact that
presently developers familiar with OO and imperative styles vastly
out number all the others, with functional coming up a distant
3rd.]
+ (Related to the previous item) Would such a language be compiled
or interpreted or something in between.
Also, if anyone chooses to discuss these issues, let's leave things like
portability and performance out of the equation UNLESS you feel these
things directly have an impact on secure coding. I think that we can
all agree that we'd desire a portable and fast-executing language
(although perhaps a slow-executing language would be more secure in
that it might slow down the propagation of malware ;-).
Finally, lets try to keep this abstract and not a grocery list of
"it should have X, Y, and Z, which by the way happens to be in
<name_of_your_pet_language_here>".
Looking for the ensuing discussion (assuming Ken thinks this is
appropriate to this lists charter).
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
"The reason you have people breaking into your software all
over the place is because your software sucks..."
-- Former whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit
