Removing function names from errors (PR 9058)

[Richard Levitte]

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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/