Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
От | Joe Conway |
---|---|
Тема | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Дата | |
Msg-id | 8f979145-e206-475a-a31b-73c977a4134c@joeconway.com обсуждение исходный текст |
Ответ на | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
|
Список | 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 по дате отправления: