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 make it seem.
Demo code generally demonstrates some fairly powerful capability; the reason it is often short and sweet is because lots of effort has gone into making it possible to do useful things with minimal effort. Unfortunately, it is often the case that much less effort has gone into making it possible to do the same thing securely, so that code is quite a bit longer. You're right, if there was more of a pushback against broken demo code, maybe more effort would go into making it easy to do things securely, instead of insecurely. I think part of the problem is that people have fallen into the trap of thinking that security is supposed to be hard and that checking all your errors is supposed to bloat your code by a factor of five, instead of wondering why library functions are designed in such a way that omitting complex logic around them fails in an insecure way. Secure code can be short and sweet, too, just not with most of the languages and tools that are currently popular. This is an old, old problem. strcpy is insecure, and any code involving strncpy or a length check will be longer and/or more complex. But this is really just an artifact of the fact that buffers don't know their own length, making an additional check necessary. There is no reason why the secure version couldn't have been just as short and sweet, it just wasn't done. Tim Hollebeek Research Scientist Teknowledge, Corp. _______________________________________________ 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