> 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]
