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 vary depending on the exact application requirements and framework. The detection is where contracts and correctness are verified, and I'd like to leave the handling of violations to some "law enforcement" module, so to speak.
Perhaps a "good enough" approach for teaching would be to raise an exception (or use assert statements for languages that don't have exceptions) whenever a problem is detected, and leave it at that. This way, the handling of the exception (logging, UI, aftermath, etc...) doesn't bloat the code and distract from the main subject, yet all unsafe conditions and errors would be highlighted and caught. It's not revolutionary, but it's better than what we have now. Would it be good enough? I can picture people deleting those assert statements that just make their programs crash ;) Pascal Meunier On 8/30/06 2:07 PM, "Michael S Hines" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > _____ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Ed Reed (Aesec) > Sent: Wednesday, August 30, 2006 1:17 PM > To: sc-l@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: [EMAIL PROTECTED] > > Subject: Re: [SC-L] How can we stop the spreading insecure coding > > examples at training classes, etc.? > > To: "Wall, Kevin" <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > Cc: SC-L@securecoding.org > > Message-ID: <mailto:[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Quoting "Wall, Kevin" <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>: > > > > > > > > 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@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php _______________________________________________ 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
