From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow tests to pass in OpenSSL FIPS mode |
Date: | 2023-03-08 09:30:21 |
Message-ID: | 8bdb05e4-3d4e-04b0-b9f1-6d57d323a56f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08.03.23 10:21, Daniel Gustafsson wrote:
>> On 8 Mar 2023, at 09:49, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>
>> It occurred to me that it would be easier to maintain this in the long run if we could enable a "fake FIPS" mode that would have the same effect but didn't require fiddling with the OpenSSL configuration or installation.
>>
>> The attached patch shows how this could work. Thoughts?
>
> - * Initialize a hash context. Note that this implementation is designed
> - * to never fail, so this always returns 0.
> + * Initialize a hash context.
> Regardless of which, we wan't this hunk since the code clearly can return -1.
I was a bit puzzled by these comments in that file. While the existing
implementations (mostly) never fail, they are clearly not *designed* to
never fail, since the parallel OpenSSL implementations can fail (which
is the point of this thread). So I would remove these comments
altogether, really.
> +#ifdef FAKE_FIPS_MODE
> I'm not enthusiastic about this. If we use this rather than OpenSSL with FIPS
> enabled we might end up missing bugs or weird behavior due to changes in
> OpenSSL that we didn't test.
Valid point. In any case, the patch is available for ad hoc testing.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-03-08 09:37:12 | Re: Allow tests to pass in OpenSSL FIPS mode |
Previous Message | Peter Eisentraut | 2023-03-08 09:28:00 | Re: Allow tests to pass in OpenSSL FIPS mode |