Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-14 Thread Michael Silk
I don't think that analogy quite fits :) If the 'grunts' aren't doing their job, then yes - let's blame them. Or at least help them find ways to do it better. -- Michael [Ed. Let's consider this the end of the thread, please. Unless someone wants to say something that is directly relevant to

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-14 Thread Dave Paris
Michael Silk wrote: I don't think that analogy quite fits :) If the 'grunts' aren't doing their job, then yes - let's blame them. Or at least help them find ways to do it better. If they're not doing their job, no need to blame them - they're critically injured, captured, or dead. ...or in the

RE: [SC-L] Theoretical question about vulnerabilities

2005-04-14 Thread David Crocker
Crispin wrote: Here's an example of a case it cannot prove: if X then Y - initial value endif ... if X then Z - Y + 1 endif The above code is correct in that Y's value is taken only when it has been initialized. But to prove the code correct, an analyzer would have to be flow

RE: [SC-L] Theoretical question about vulnerabilities

2005-04-14 Thread David Crocker
Crispin Cowan wrote: Precisely because statically proven array bounds checking is Turing Hard, that is not how such languages work. Rather, languages that guarantee array bounds insert dynamic checks on every array reference, and then use static checking to remove all of the dynamic checks that