On Wed, Aug 14, 2002 at 05:05:27PM +0300, 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.
Maybe, impossible is a too strong word here. Verifiable secret sharing might be a way to detect errors below threshold and ignore them. One may think two sets of hosts talking to each other just like SSL client and server do it. Well, I guess it not for prime time yet > 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. > > arne > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- Naina library: http://www.unity.net/~vf/naina_r1.tgz ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
