From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Cryptohash OpenSSL error queue in FIPS enabled builds |
Date: | 2022-05-09 00:28:14 |
Message-ID: | YnhgHpD4onvvpvjQ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 26, 2022 at 03:15:24PM +0200, Daniel Gustafsson wrote:
> On 26 Apr 2022, at 03:55, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-05-09 01:14:36 | Re: failures in t/031_recovery_conflict.pl on CI |
Previous Message | Michael Paquier | 2022-05-09 00:24:06 | Re: Possible corruption by CreateRestartPoint at promotion |