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
      + (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

Looking for the ensuing discussion (assuming Ken thinks this is
appropriate to this lists charter).

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

Reply via email to