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.
arne
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
