Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
От | Daniel Gustafsson |
---|---|
Тема | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Дата | |
Msg-id | 77767A6C-1C44-4167-AE13-C4A070A38E26@yesql.se обсуждение исходный текст |
Ответ на | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
|
Список | pgsql-hackers |
> On 21 Jan 2025, at 18:51, Joe Conway <mail@joeconway.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 ornot. I think that would be a useful addition, but I guess one could derive the answer based on whether these functionswork 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
В списке pgsql-hackers по дате отправления: