Message: 1
Date: Tue, 29 Aug 2006 15:48:17 -0400
From: [EMAIL PROTECTED]
Subject: Re: [SC-L] How can we stop the spreading insecure coding
examples at training classes, etc.?
To: "Wall, Kevin" [EMAIL PROTECTED]
Cc: SC-L@securecoding.org
Message-ID: [EMAIL PROTECTED]
Content-Type:
Really, the root of the problem is the fact that the simple version
is short and easy to understand, and the secure version is five
times longer and completely unreadable. While there always is some
additional complexity inherent in a secure version, it is nowhere
near as bad as current toolkits
a simple structure that provides for errors would go a long
way...
If - then - else - on error
Do - end - on error
Let x = y - on error
Let x = function() on error
etc...
The problem is writing code without thinking of the
possible errors that might arise. This forces you to think about
Worse is when it works in unintended ways without producing an error. The
code has to detect whenever something doesn't match a white list of expected
program states and inputs. I think that in example code, the detection is
more important than the subsequent handling because the handling will
William L. Anderson wrote:
Years ago I had to write a Fortran
program as part of a job interview. The program problem was quite
simple, and I wrote one that checked for as many errors as I could think
of. My interviewer wanted to know what took me so long. I didn't get an
offer.
Years ago
