Steve Furlong wrote: > Other important questions for programmers are, how good are you? How > good does the process allow you to be? > > My answers are, I'm quite a good programmer. (Pardon the ego.) I'm > careful and methodical and very seldom have buffer overruns or unfreed > memory even in my first drafts. For me, my expected code quality in C > and C++ is balanced against the black box behaviour of Java's runtime > engine. (To be clear: I don't suspect Sun of putting back doors in > their engine.) And I'm experienced enough and old enough that I can > hold my own in pissing contests with project managers who want to cut > corners in order to ship a day earlier. > > Implementation quality could be considered in the threat model. I've > generally taken the programmers into account when designing a system, > but I hadn't explicitly thought of well-meaning-but-incompetent > programmers as part of the threat. Guess I should.
note that compared to some other languages .... a lot of C-language buffer overflows can be attributed to C requiring the programmer to keep track and manage various lengths (where in some number of other languages, buffer length characteristics are built into basic object characteristics and operations). i know of at least one production implemented tcp/ip stack done in pascal ... which had no known buffer related problems compared to the possibly hundreds of thousands that have appeared in c-language based implementations. large collection of past posts on buffer overflow related vulneabilities http://www.garlic.com/~lynn/subpubkey.html#overflow part of the issue is that there are hundreds of thousands of applicantations being written ... with possibly only a couple hundred mistake-free, careful programmers available world-wide. a possible solution is to create a time-machine that allows for the limited number of mistake-free, careful programmers to have several thousand hour work days (along with the medical support to allow them to never sleep). there are separate class of vulnerabilities related to dangling buffer pointers and syncronization problems ... which are common to languages that place the burden of allocation/deallocation burden on the programmer (however, that is a distinct vulneability from c-language placing burden of length management on the programmer ... and the resulting mistakces). some languages like apl ... large collection of past apl posts http://www.garlic.com/~lynn/subtopic.html#hone have abstracted both object length characteristics as well as storage allocation/deallocation operations. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
