openssl: Error reporting and reason table generation for providers

NOTE: this is an age old issue that has existed since the beginning of ENGINEs

Providers will have to be able to report errors, and we already have the mechanisms for doing so “the OpenSSL way” via put_error and add_error_vdata upcalls. However, is that sufficient?

As everyone (or well, some at least), our error codes contain quite a lot of information:

  1. 8-bit “library” code (in terms we tend to use today, that’s sub-system code)
  2. 12-bit function code
  3. 12-bit reason code

How much of this is needed for a provider? Logically, the “library” code should be the same for a whole provider, and the value function codes have been questioned before… Reason codes and associated printable strings are another matter, they are fairly universally accepted error reporting tools (see errno and strerror on Unix, or corresponding on other platforms).

Furthermore, reason strings in OpenSSL is a fairly complicated matter, and is done by using util/mkerr.pl, which scans the source for function code macros and reason code macros, and generates header files to define those macros (give them numbers) and source files for the associated strings. However, that script is internal and is never made publicly available (which has always been a problem for any ENGINE author).

So the question is, how can we make it simpler for provider authors? Can we make it in such a way that they just need to provide reason codes and strings as a simple array of < number, string > tuples, and then report the reason numbers as they see fit? As an alternative, should providers offer a strerror like function for libcrypto to call when it needs a string?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (18 by maintainers)

Most upvoted comments

on the other hand seeing function names in error reports can be very helpful so I do hope they will still be inserted automatically by some other means.

I have some unpublished work going on that does this. Also, see this discussion on openssl-project where this was discussed, mostly in terms of a new couple of functions, ERR_raise_error and ERR_raise_error_debug.

Thanks for your suggestion re OPENSSL_FUNC, it expands on the variants that have already been mentioned in the mailing thread I linked to.

+1 for ditching function codes. I’ve wondered several times why they exist.

__FUNCTION__ (gcc) or __func__ (c99) would be a possible partial substitute that is more readable.

I like the ERR_raise_error suggestion with a format argument. This might enable a reduction in the number of reason codes and still provide better feedback to our users.

@richsalz, I do recall a discussion we had a few years ago, where you wanted to get rid of the function codes and I didn’t. Since then, I have had the time to rethink that, and I don’t really see a need for them any more.

On reason codes, it’s been suggested to me that providers should report errors back to libcrypto in string form only. I’m not sure I’m keen on the idea, but will not deny it either.