Coding with errors in mind - a solution?

[band at acm.org (William L. Anderson)]

Michael, this is an interesting note. 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.

My 2 cents is that people are not really willing to pay for software
with the kinds of qualities that we talk about in this list (which is
about more than security).

Bill Anderson


Michael S Hines wrote:
> 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 the consequences of
> executing a command...
>  
> Where 'error' is doing something intelligent when the original command
> doesn't work...   
>  
> Just a brainstorm....... any merit to it?
>  
> Mike Hines
> mshines at purdue.edu <mailto:mshines at purdue.edu>
>
> *From:* sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] *On Behalf Of *Ed Reed (Aesec)
> *Sent:* Wednesday, August 30, 2006 1:17 PM
> *To:* sc-l at securecoding.org
> *Subject:* [SC-L] e: How can we stop the spreading insecure coding
> examples at, training classes, etc.?
>
> > Message: 1
> > Date: Tue, 29 Aug 2006 15:48:17 -0400
> > From: pmeunier at purdue.edu <mailto:pmeunier at purdue.edu>
> > Subject: Re: [SC-L] How can we stop the spreading insecure coding
> >      examples        at training classes, etc.?
> > To: "Wall, Kevin" <Kevin.Wall at qwest.com> <mailto:Kevin.Wall at qwest.com>
> > Cc: SC-L at securecoding.org <mailto:SC-L at securecoding.org>
> > Message-ID: <1156880897.44f49a01620aa at webmail.purdue.edu> <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Quoting "Wall, Kevin" <Kevin.Wall at qwest.com> <mailto:Kevin.Wall at qwest.com>:
> >
> >
> >   
> > > I think that this practice of leaving out the "security
> > > details" to just make the demo code short and sweet has got
> > > to stop. Or minimally, we have to make the code that people
> > > copy-and-paste from have all the proper security checks even
> > > if we don't cover them in training. If we're lucky, maybe
> > > they won't delete them when the re-use the code.
> > >     
> > I agree, and would like to extend it: security should be discussed *at the same
> > time* that a topic is.  Teaching security in a separate class, like I have been
> > doing, reaches only a fraction of the audience, and reinforces an attitude of
> > security as an afterthought, or security as an option.  Comments in the code
> > should explain (or refer to explanations of) why changing or deleting those
> > lines is a bad idea.  
> >
> > However, I'm afraid that it would irritate students, and make security the new
> > "grammar and spelling" for which points are deducted from "perfectly valid
> > write-ups" (i.e., "it's my ideas that count, not how well I spell").  
> The same used to be said about unstructured programming examples
> (computed gotos, spaghetti code, multiple entry and exit points from
> functions, etc).  We got past it.
>
> We need a similar revolution in thought with regard to security, and
> some one to take the lead on providing clear, crisp examples of coding
> style that is more secure by its nature.  I don't have one handy - but
> that's my wish.
>
> Ed
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php