Removing function names from errors (PR 9058)

[Matt Caswell]

On 12/06/2019 04:51, Richard Levitte wrote:
> Many of us, both past and present, have looked at the error reporting
> code and wante to change it somehow.  There's currently a PR, 9058,
> which covers one aspect, the function name indicator.
> 
> A -1 was raised early on for the purpose of starting a discussion, and
> eventually (possibly?) a vote.
> 
> A discussion point in that PR is whether it's still interesting to
> keep information on the system function/callback that was called when
> we're reporting a system error, i.e. this type of error report:
> 
>     SYSerr(SYS_F_FSTAT, errno);
> 
> (incidently, there's another PR, 9072, which changes those to
> 'SYSerr("fstat", errno)')
> 
> So, the main points of discussion seem to be:
> 
> - should we remove function indicators in our error reporting?
> - should we make an exception for system errors (SYSerr())?
> 
> Cheers,
> Richard
> 
> P.S. I'm personally not entirely sure that we need an actual vote, if
> this discussion shows that we all agree.  Perhaps to confirm and make
> the decision formally solid?
> 


The big problem with having function codes in the errors is that they are not
stable across releases (including patch releases). People can and do write
application code that checks for particular types of errors occurring - and
those checks can include checking the function code. If the underlying code gets
refactored then the functions that are the source of the error can change (even
across patch releases).

OTOH I do find them quite helpful from a debugging perspective, e.g. when people
send in questions along the lines of "I got this error what does it mean/how do
I fix it" - although what is actually useful is usually the function name rather
than the function code itself. Usually the same information can be figured out
if you know the OpenSSL version, filename and line number for the error (which
is often but not always also included in the error reports)...very often people
neglect to mention the OpenSSL version they are using. In that case knowing the
function name can often help to infer it.

Another concern is that removing function numbers is a breaking change. But,
then again, as I said above these numbers are unstable anyway, so perhaps that's
a good thing.

I also think we need to reconsider the whole error reporting concept in the
light of providers. We cannot and should not expect providers to be using the
OpenSSL internal system for generating error codes. So we need to have the
ability for providers to be able to register errors on the stack without using
OpenSSL built-in error codes. We're getting away with this so far for the
default and fips providers because they are "our" providers, so we can ensure
all the required function/reason codes are present in libcrypto. That isn't true
for third party providers.

I suspect if we take away function codes then we will need a vote because it is
a breaking change.

Matt