> On 21 Jan 2025, at 18:51, Joe Conway <m...@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 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
