Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

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

In response to

Responses

Browse pgsql-hackers by date

  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