Arne Ansper wrote: > > On Wed, 14 Aug 2002, Ben Laurie wrote: > > >>The point is that the application is now in an inconsistent state and >>cannot reliably know anything. Even returning from a function could >>cause an exploit. The only safe thing to do is abort (now I think about >>it, probably die() shouldn't even print an error message). > > > the question is how and when should we try to catch those inconsistencies. > > there is infinite number of ways how program can get into inconsistent > state. programming error in openssl, programming error in application, > error in kernel, error in hardware, power surge, etc. > > it's possible to detect some of the inconsistencies and it is impossible > to detect all of them. detecting all the possible inconsistencies is > impossible :) i mean: the additional code that is needed to detect all > that we can detect is so huge that the real working code gets lost in it. > if we add too much checks for "impossible" conditions then the code > becomes unreadable and unmaintainable. > > nobody will later remember why all those checks are there, which ones are > for impossible conditions and which one are real input checks and why > those checks look like they do. as a result some checks are finally just > commented out (like the one in asn1_lib.c was). > > i think that one should try to catch its own programming errors and not to > worry too much about other's. for catching your own errors assert's and > test programs that trigger various conditions are useful. but putting lots > of inconsistency checks into the production code is not a good idea. > > when i did a first patch i did not recognize that some of those die's are > for impossible conditions. todayt i would replace those die's that check > for impossible conditions with asserts.
Personally, I would have used asserts, but people (correctly) objected that these are disabled in non-debug versions, which is why I replaced them with die. I never disable asserts myself but I guess we should be friendly to those who do (OTOH, they've already made the tacit declaration that they want to continue to run when bad things happen, so, hmm). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
