> Removing all the problems you can find is simply not a reliable way to > develop software. You have to design the software such that there aren't > problems, then remove any that slipped through. You can't use testing as the > way to create the guarantee in the first place.
Heh :-) I totally agree with that!! -paul On Jan 22, 2008 8:47 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > > > Guaranteed to work? Who's doing the indemnification? > > The point of a guarantee is that it is much less likely to change on > another > machine or if a library is upgraded and compatability is claimed. Of > course, > things can still go wrong. > > When bugs are fixed in a library or a new version claims compatability > with > an old version, every effort it made to ensure that whatever guarantees > were > provided with the old version are still met by the new version. If you > stick > to those guarantees, and they are sufficient that you don't need > additional > assumptions, you are much less likely to run into a problem if the library > is upgraded or otherwise different from the one you tested with. > > > Security's all about trade-offs. If you can make some simplifying > > assumptions that cut out large parts of code you might well be better > off. > > The risk that a dynamic library on another machine will break his > assumptions is greater than any benefit from eliminating code. This is > especially true in this case, where it's hard to imagine any risk created > by > adding locks (other than deadlock, which would seem to be very unlikely to > pose a security risk). > > Removing all the problems you can find is simply not a reliable way to > develop software. You have to design the software such that there aren't > problems, then remove any that slipped through. You can't use testing as > the > way to create the guarantee in the first place. > > The design has to be bug-resistant in the first place. > > To use an engineering analogy, imagine if you design a bridge. You fail to > specify what type of steel to use, but when you test, you pick a very > high-quality steel. Did you validate the bridge design? > > The answer is no, because you tested with only one steel, and the design > isn't limited to that one steel. > > On the flip side, if you design to the guarantees the steel manufacturer > provides, specify steel that meets those guarantees, and test with that > steel, then you have a validated design. > > Responding to Paul: > > > Since OpenSSL can be compiled as a non-locking, > > single-threaded library, I'm trying to answer the question: > > If I have one context per thread, will these contexts trash > > each others data when OpenSSL is compiled with no locking. > > The first 4 points of my list are the trashings that could take place. > > > Now I just need the complete list :-) > > You missed step 1. As far as I know, *no* platform provides that code > compiled single-threaded is thread-safe in fundamental ways. For example, > AFAIK, there is no guarantee that 'malloc' won't be "optimized" in a > single-threaded compile in ways that break horribly on multi-threaded > code. > > You need the completel list for your *platform* and an assurance that no > new > entries will be added to that list on any platform your code will compile > on > or run on. > > Absent such a guarantee, your attempt is a disaster waiting to happen even > if it works in the first place. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] >
