Improve use of IDs in ERR_raise()

[levitte]

Describe the bug

I was looking around at the source, in this case oqsprov/oqsprov.c, which I noticed these sorts of calls:

https://github.com/open-quantum-safe/oqs-provider/blob/4dec0fe04f4e9814775026a657e40045fdf075d3/oqsprov/oqsprov.c#L523

That's really not recommended. Consider if there are two providers doing this, having each their own series of reason codes, but both using ERR_LIB_USER... that'll lead to some confusion.

The recommended way is to make your own error reporting routines, based on the upcalls OSSL_FUNC_CORE_NEW_ERROR, OSSL_FUNC_CORE_SET_ERROR_DEBUG and OSSL_FUNC_CORE_VSET_ERROR.

[levitte]

I do understand that the recommended way may be daunting... I have written a small provider error library that may be useful, though, as part of libprov. The files of interest in this case are https://github.com/provider-corner/libprov/blob/main/err.c and https://github.com/provider-corner/libprov/blob/main/include/prov/err.h. If you want to see a usage example, have a look at the vigenere toy

[baentsch]

Thanks for bringing this up, @levitte . Looking at the mechanism you're proposing in https://github.com/provider-corner/libprov, the term "daunting" indeed seems apt.

If this

Consider if there are two providers doing this, having each their own series of reason codes, but both using ERR_LIB_USER... that'll lead to some confusion.

indeed is the only reason (?), wouldn't it be sufficient to register a "local provider ID" by calling ERR_get_next_error_library to avoid this confusion? Doing this once, e.g., during provider init, instead of introducing yet more "state handling mechanisms" (that one can get wrong -- and I usually do :-() into the provider(s) seems to resolve the issue too, no?

[levitte]

In retrospect, maybe you're right. I dunno. I can't quite recall the reasoning we made back then...