On Thu, 13 Jun 2019 18:26:41 +0200, Salz, Rich wrote: > > > The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > > CODES.* Each error code appears in exactly one place, and we could > > eventually build up documentation explaining what they mean, the causes, > > and how to address this. This means, we don't use ERR_R_MALLOC when trying > > to create an RSA key, for example, but rather a handful of new errors for > > ERR_R_RSA_CANT_CREATE_D, ...CANT_CREATE_N, etc. That is a big job, albeit > > mostly a tedious one. > > I got some feedback on- and off-list about this. Most of it was > "surely you can't be serious." I am, and stop calling me > Shirley. :) Let me add some details. First, recall that OpenSSL has > an error stack, and that as errors are "unwound" each function can > add its own error code to that stack. This naturally leads to the > point where the first entry has the most detailed error, "malloc > failed" and the last entry has the most application-oriented error > "Could not create RSA key"; along the way are "Could not create d" > and "Could not create secure bignum" errors. I hope that makes more > sense. > > HOWEVER, this point (which got the most comments) was a side-note to > the main point of my email, which gave some reasons why I think > including the function code is a bad idea.
So basically, what you're actually saying is that we should add additional errors up the call stack... so if some function called OPENSSL_zalloc(), it should be perfectly OK to raise a ERR_R_MALLOC_FAILURE, but functions above should *add* things like WHATEVER_R_KEY_CREATE_FAILURE, etc etc etc, thereby creating that backtrace that Tim talks about. A point here is that the application may want to find out if there was an allocation error -- at which point it might choose to simply bail -- or some other error that prevented the key to be created (insecure amount of bits, say?) -- at which point it might choose to try and mitigate. The question is what's easier for the application, getting the wanted information as a top error or having to walk to the bottom of the error stack to figure things out. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
