On Tue, Apr 26, 2022 at 03:15:24PM +0200, Daniel Gustafsson wrote:
> On 26 Apr 2022, at 03:55, Michael Paquier <michael@paquier.xyz> wrote:
>> I am a bit annoyed to assume that having only a localized
>> ERR_clear_error() in the error code path of the init() call is the
>> only problem that would occur, only because that's the first one we'd
>> see in a hash computation.
>
> It's also the only one in this case since the computation won't get past the
> init step with the error no? The queue will be cleared for each computation so
> the risk of cross contamination is removed.
I was wondering about the case where an error is applied while
updating or finishing the cryptohash, not just the creation or the
initialization. But cleaning up the queue when beginning a
computation is fine enough.
>> Okay. I did not recall the full error stack used in pgcrypto. It is
>> annoying to not get from OpenSSL the details of the error, though.
>> With FIPS enabled, one computing a hash with pgcrypto would just know
>> about the initialization error, but would miss why the computation
>> failed. It looks like we could use a new error code to tell
>> px_strerror() to look at the OpenSSL error queue instead of one of the
>> hardcoded strings. Just saying.
>
> I looked at that briefly, and might revisit it during the 16 cycle, but it does
> have a smell of diminishing returns to it. With non-OpenSSL code ripped out
> from pgcrypto it's clearly more interesting than before.
Clearly.
For the sake of the archives, this patch series has been applied as
17ec5fa, 0250a16 and ee97d46.
--
Michael