Thank you for your reply. The motivation behind this proposal was my concern that, even if FIPS mode is enabled at the OS level, it might not be enabled in the OpenSSL instance used by PostgreSQL because of an incorrect OpenSSL configuration file path or a configuration error. I thought that checking `fips_mode()` from within PostgreSQL could help detect such a mismatch.
However, after reconsidering this, I agree that this use case is primarily about verifying OpenSSL's configuration and runtime state. Exposing OpenSSL-specific state from PostgreSQL core for that purpose would extend PostgreSQL's scope of responsibility too far. I also understand your concern that this could set a precedent for exposing similar details about other external libraries. I agree that this use case alone does not justify moving the function to core. Thank you for your feedback. Koshi Shibagaki FUJITSU LIMITED https://www.fujitsu.com/ ________________________________ 差出人: Daniel Gustafsson <[email protected]> 送信日時: 2026年9月7日 17:12 宛先: Shibagaki, Koshi/柴垣 向志 <[email protected]> CC: [email protected] <[email protected]> 件名: Re: [PATCH] Move pgcrypto's fips_mode() function to core > On 7 Sep 2026, at 07:49, Koshi Shibagaki (Fujitsu) > <[email protected]> wrote: > Do you think it's a good idea to port the fips_mode() to core? The reason for it being useful in pgcrypto is that pgcrypto always contains built-in crypto which isn't FIPS certified. The builtin_crypto_enabled GUC and fips_mode() were added to help users remain FIPS compliant. When PostgreSQL is compiled with a TLS library (OpenSSL or LibreSSL) it doesn't compile any built-in crypto at all, so all crypto operations will use OpenSSL and thus be subject to FIPS compliance. Due to this I'm not convinced there is a usecase for moving this to core. I also don't want set a precedent of PostgreSQL exposing details about libraries since there is an endless amount of similar functions which could be advocated for. -- Daniel Gustafsson
