Re: Replace current implementations in crypt() and gen_salt() to OpenSSL - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date
Msg-id 8f979145-e206-475a-a31b-73c977a4134c@joeconway.com
Whole thread Raw
In response to Re: Replace current implementations in crypt() and gen_salt() to OpenSSL  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
List pgsql-hackers
On 1/21/25 06:39, Daniel Gustafsson wrote:
>> On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu) <shibagaki.koshi@fujitsu.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



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Year of first commit
Next
From: Michel Pelletier
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql