On Thu, Sep 4, 2025 at 1:26 AM Collin Funk <[email protected]> wrote:
> Simon Josefsson <[email protected]> writes: > > > Collin Funk <[email protected]> writes: > > > >> Second, I used xalloc-die as a conditional dependency. This is because > >> the EVP functions are documented as returning 0 on failure. In practice, > >> I can only see this being the case for EVP_MD_CTX_create, but that > >> should be rare (e.g. OOM). I would rather not change the prototypes to > >> be different than the other digests in Gnulib, so there is no way to > >> return errors back to the caller. This shouldn't matter for Coreutils, > >> but calling abort in libraries is not great, in my opinion. Using > >> xalloc_die is only slightly more friendly. > > > > I think this is deeply problematic -- I haven't needed SHA3 in any > > library so far, but it is a question of time. And libraries shouldn't > > have to use gnulib's xalloc-die. What is the actual problem here? Is > > it that the gnulib APIs doesn't provide a way to signal an error, but > > the OpenSSL API have it? Then I think we should modify the gnulib API > > to be able to signal an error. That seems like the proper solution to > > me, even if error handling often is a pain. > > Ideally OpenSSL would provide the typical low-level digest API so you > could allocate the context on the stack and use them. My later patch > allocates it on the stack, so it will only abort through programmer > error (e.g. calling sha3_update without calling sha3_init). > EVP_MD_CTX and friends used to be actual data structures that could be placed on the stack. OpenSSL made them opaque at OpenSSL v1.1.0. I was not thrilled with the change because it meant we had to go into the memory manager for a heap allocation more often. (I was more concerned with BN_CTX allocations for big integers). Maybe I can change them all return int/bool later, but it will require > some work. At least Emacs uses them through a function pointer Jeff
