The programmer is neither the application architect nor the system engineer. In some cases he is. Either way, it doesn't matter. I'm not asking the programmer to re-design the application, I'm asking them to just program the design 'correctly' rather than 'with bugs' Except that sometimes
At 4:21 PM -0400 4/11/05, Dave Paris wrote: Joel Kamentz wrote: Re: bridges and stuff. I'm tempted to argue (though not with certainty) that it seems that the bridge analogy is flawed in another way -- that of the environment. While many programming languages have similarities and many
David Crocker wrote: 3. Cross-site scripting. This is a particular form of HTML injection and would be caught by the proof process in a similar way to SQL injection, provided that the specification included a notion of the generated HTML being well-formed. If that was missing from the
Nash wrote: ** It would be extremely interesting to know how many exploits could be expected after a reasonable period of execution time. It seems that as execution time went up we'd be less likely to have an exploit just show up. My intuition could be completely wrong, though. I would think
Pascal Meunier [EMAIL PROTECTED] writes Do you think it is possible to enumerate all the ways all vulnerabilities can be created? Is the set of all possible exploitable programming mistakes bounded? I believe that one can make a Turing machine halting argument to show that this is impossible.
I would question you if you suggested to me that you always assume to _NOT_ include 'security' and only _DO_ include security if someone asks. Security is not a single thing that is included or omitted. Again, in my experience that is not true. Programs that are labelled 'Secure' vs
Or until you find a bug in your automated prover. Or, worse, discover that a vulnerability exists despite your proof, meaning that you either missed a loophole in your spec or your prover has a bug, and you don't have the slightest idea which. On that basis, can I presume that you believe