From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com> |
Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Date: | 2025-01-21 17:51:35 |
Message-ID: | 8f979145-e206-475a-a31b-73c977a4134c@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/21/25 06:39, Daniel Gustafsson wrote:
>> On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu) <shibagaki(dot)koshi(at)fujitsu(dot)com> wrote:
>>
>> Thank you for moving this discussion forward.
>>
>>> Maybe we could document that the test should fail if fips is enabled?
>>>
>>> FWIW I have not tested at all on a fips enabled machine. I will see about doing
>>> that...
>> I tested all on a fips enabled machine and test failed.
>
> Did the patch as posted fail, or did it fail when you changed the GUC to follow
> the fips mode? I assume it's the latter since the code in question doesn't
> care about FIPS at all (hence this patch). Re-testing it again against OpenSSL
> 3.4 with FIPS enabled as well as disabled I can't reproduce any failure.
>
>> Since all tests have been made to run even with FIPS enabled in PostgreSQL 17,
>> it would be ideal for this test to follow suit.
>
> The work which was done was to ensure that the tests passes regardless of if
> FIPS is enabled or not, they were not designed to test FIPS.
>
> After thinking about I don't think we need an alternative output file since it
> won't add any testing:
>
>> +SET pgcrypto.builtin_crypto_enabled = fips;
>> +UPDATE ctest SET salt = gen_salt('des');
>> +ERROR: use of non-FIPS certified crypto not allowed when OpenSSL is in FIPS mode
>> +UPDATE ctest SET res = crypt(data, salt);
>
> If we add such an alternative output we also need the other case where FIPS is
> disabled and the functions work, which means we add no test coverage at all as
> both options are allowed to pass.
I was thinking the same -- perhaps just an SQL comment that says
something like: "-- expected to fail when in fips mode"
or similar.
I also wonder if it is worthwhile to expose a SQL callable function to
indicate whether the backend is in fips mode or not. I think that would
be a useful addition, but I guess one could derive the answer based on
whether these functions work or not when "builtin_crypto_enabled = fips"
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Pelletier | 2025-01-21 18:05:48 | Re: Using Expanded Objects other than Arrays from plpgsql |
Previous Message | Álvaro Herrera | 2025-01-21 17:50:14 | Re: Year of first commit |