On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote:

You don't teach proofs - not really. The elementary and junior high
curriculum generally does not contain anything about proofs

I was talking about college students because that's when I was properly taught programming. That may no longer be true. But in maths, I *was* taught how to do proper proofs in high school (from 7th grade on, when we had Geometry). I may have been unusually lucky.

I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science. It increasingly makes sense
given the failures up to this point.

The problem then is that every Joe, Dick, and Harry out there who can get hello world to compile think they're artists. Seriously, unlike art, programming is usually not a vehicle for one's creative urges, but a tool to get a job done, as you yourself say. (I hesitate to use the word "science" as an antonym to "art" here, perhaps "craft" would be better.)

Unfortunately, security assumptions are rarely written down so I don't
see how they can be enforced at the language or compiler level.

Here you make a patently bad assumption yourself. It should be possible
for the compiler to automatically protect against overflows, as an

Sure, for certain languages and certain classes of well-understood problems, compiler or language support can be engineered. But my point stands: security assumptions are rarely written down. This is because they are taken to be self-evident and not in need of explicit formulation. Also, they depend on the domain. If I express a hospital drug disbursal system in any of the common general-purpose programming languages, the assumption that one cannot be a doctor and a nurse at the same time is usually implicit. I challenge you to develop Java or C ++ support that will capture any flaw in the implementation of this particular RBAC *without* having to make that assumption explicit.

Safe input validation and output encoding could also be forced
at a given level.

Really? I'd be interested in hearing about such techniques that cannot be short-cut (which, as you state, is one big factor for security defects in software).


Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.

Reply via email to