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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>, "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 20:47:08
Message-ID: 77767A6C-1C44-4167-AE13-C4A070A38E26@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 21 Jan 2025, at 18:51, Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 1/21/25 06:39, Daniel Gustafsson wrote:

>> 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.

But it isn't actually expected to fail when in FIPS mode since the test sets
the GUC to off. It would only fail (due to different error message) if the GUC
in the testfile was changed and I don't we need to cater for manual alterings
of the testdata.

> 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"

It could indeed be useful, but I doubt we can make it portable to check for
anything but the state of OpenSSL. If the operating system has a FIPS mode
then we won't capture that. That might not be a problem since if the OS is in
FIPS mode then OpenSSL most likely will be too but we can't guarantee it.
Definitely worth thinking about, I can see it being useful especially in DBaaS
environments to ensure that the libraries are in the expected state.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-01-21 20:53:53 Re: pg_dump --no-comments confusion
Previous Message Tom Lane 2025-01-21 20:23:31 Re: attndims, typndims still not enforced, but make the value within a sane threshold