Re: Cryptohash OpenSSL error queue in FIPS enabled builds

> On 22 Apr 2022, at 19:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:

>> Consuming all (both) errors and creating a concatenated string seems overkill
>> as it would alter the API from a const error string to something that needs
>> freeing etc (also, very few OpenSSL consumers actually drain the queue, OpenSSL
>> themselves don't).  Skimming the OpenSSL code I was unable to find another
>> example of two errors generated.  The attached calls ERR_clear_error() as how
>> we do in libpq in order to avoid consuming earlier errors.
> 
> This seems quite messy.  How would clearing the queue *before* creating
> the object improve matters?  

We know there won't be any leftovers which would make us display the wrong
message.

> It seems like that solution means you're leaving an extra error in the queue to
> break unrelated code.  Wouldn't it be better to clear after grabbing the error?
> (Or maybe do both.)

That's a very good point, doing it in both ends of the operation is better
here.

> Also, a comment seems advisable.

Agreed.

--
Daniel Gustafsson		https://vmware.com/