Bodo Moeller wrote: > Ben Laurie <[EMAIL PROTECTED]>: > > >> As noted elsewhere, I really object to returning internal errors! >> It makes no sense to attempt to continue after the impossible has >> occurred. > > > If we could be absolutely sure that these events are strictly > "impossible", then it wouldn't make a difference if we call abort(), > return an internal error, or post a coredump to alt.binaries: nothing > of this could ever happen. In fact we don't "continue" -- we return > an error, meaning that the current handshake will be aborted.
Yes, and the application will continue as if it were sensible to do so. > Of course the point is that one of the events might not be that > impossible after all if there are still hidden bugs. So what would > this mean? If the internal structures are totally screwed up, then > an abort() might be the best we can do. Exactly. > But that's not the case for those internal error cases (or the one > that was considered an internal error in the initial patch but turned > out to be a protocol error): what really may have happened is that a > buffer that has been allocated turns out to be of insufficient size. The fact that this was not an internal error does not alter my point. Yes, in this case, an error should be returned, but that is not so for all the cases. > We test this *before* accessing the buffer and return an internal > error *instead*, so what bad thing could happen? The application could continue to run with corrupt memory, thus exposing it to an unknown exploit, in the case where the error really is internal and not a protocol error. 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]
