Removing function names from errors (PR 9058)

[Richard Levitte]

The discussion so far has touched on a number of items that aren't
necessarily the same thing:

- the instability of function codes.
- debugging information
- display of errors

and then, the point that no one talks about but that's the main reason
error codes in general exist at all:

- an application's need to figure out what went wrong and how to react


The current error codes have these items added together:

- library code (I'll touch on that further down)
- function code (debugging information)
- reason code


If we look at it from the perspective of the application author,
what's most often needed are reliable error/reason codes (to check and
to react appropriatly to) and associated reason strings (for display).
For the application author, it would normally be completely
uninteresting exactly which function the error happened in (think
about it, when's the last time you wanted to know exactly which
internal function in libc raised the EAGAIN you just got?).  For the
application author, the interesting bit is usually "what went wrong?"
(reason) and "what did I call?" (they already know that).


If we look at *our* needs as library writers, then the exact location
that raised the error is interesting, of course!  But then, is it
interesting in the form of codes, or are we rather interested in the
text form?  I dunno about you, but I don't give a damn about the
actual library and function codes, I look at the displayed library
names and function names.  (and yet, they aren't necessarily enough
without knowing the OpenSSL version).


Finally, if we look at it from a provider author's perspective,
dealing with all these different codes is quite hard.  Ideally, a
provider author should just need to deal with their own reason codes
and associated strings, and that's about it.


What I would like to see is a simplified error system that delivers
reason codes, and attached extra text information.  That text
information could have two parts, where one is debugging information
(__FILE__, __LINE__, __FUNC__, and possibly exact commit hash
generated with 'git archive', see "export-subst" in gitattributes(5)),
and the other is the extra data added with the likes of
ERR_add_error_data().
We certainly already have the infrastructure to allow this, the
modifications needed wouldn't be that big.


On the subject of 'openssl errstr', it's abssolutely fine for errors
raised within our libraries, but outside of that, it's useless.  This
is an issue with engines that no one has spoken about but that has
been there all along.  See, engines, if they use our error reporting
system at all, usually allocate a new library code dynamically, by
calling ERR_get_next_error_library().  Since the library code may
differ from one time to the next, the complete error codes raised will
differ, giving 'openssl errstr' an impossible job, even if the engine
is loaded.
This issue is exactly the same for provider modules.  This makes
library codes less than useful outside of our libraries.


I digress..  the main point is, however, that we need to keep the
application author's needs from our needs.  That affects how we look
at error codes.


Cheers,
Richard


On Wed, 12 Jun 2019 05:51:44 +0200,
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?
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/