Peter Amey wrote: Yes, the posit and verify approach. We adopted this because we think there are problems with refining specs into code. One problem is that there can be (usually will be) more than one valid way of implementing a spec. For example, the spec may make the abstract assertion
Does anyone have pointers to articles on designing API's so that they are easy to use securely? Not specifically related to security, but http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161 is one of the better things I've seen about designing APIs. Nick
At 5:30 PM -0600 7/12/04, Jared W. Robinson wrote: I read the paper, and found it interesting. I read the statistic 50 percent of security problems are the result of design flaws. Where does that number come from? Experience? I would say it comes from sloppy wording. At best, the author might
ljknews wrote: The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer?