On 1/21/25 06:39, Daniel Gustafsson wrote:
On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu)
<shibagaki.ko...@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
