[PATCH] Move pgcrypto's fips_mode() function to core
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253697psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 06:58 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253697_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253697_1 && git checkout t253697_1Patchset v1 (message #1) is on t253697_1
Hi,
I'd like to get feedback on moving pgcrypto's fips_mode() function to
core.
fips_mode() reports whether OpenSSL is running with FIPS mode.
This information is not specific to pgcrypto. OpenSSL is also used by
cryptographic operations in core, such as server-side TLS and the hash
and HMAC operations used by SCRAM authentication. Making this information
available in core would allow users to check the OpenSSL configuration
without installing the pgcrypto extension.
The attached patch adds pg_catalog.fips_mode() and moves the
OpenSSL-specific detection code to a common helper. It returns false
when PostgreSQL is built without OpenSSL.
For backward compatibility, pgcrypto.fips_mode() remains available as a
wrapper around the core function.
This follows an existing manner, see gen_random_uuid().
The documentation clarifies that this function reports the OpenSSL
configuration only and does not establish that the PostgreSQL server as
a whole is FIPS compliant.
Do you think it's a good idea to port the fips_mode() to core?
Also, what should the function return if the build disables OpenSSL?
For now, it always returns false.
Best regards,
Koshi Shibagaki
FUJITSU LIMITED
https://www.fujitsu.com/
On 7 Sep 2026, at 07:49, Koshi Shibagaki (Fujitsu) <shibagaki.koshi@fujitsu.com> 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
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 <daniel@yesql.se>
送信日時: 2026年9月7日 17:12
宛先: Shibagaki, Koshi/柴垣 向志 <shibagaki.koshi@fujitsu.com>
CC: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
件名: Re: [PATCH] Move pgcrypto's fips_mode() function to core
On 7 Sep 2026, at 07:49, Koshi Shibagaki (Fujitsu) <shibagaki.koshi@fujitsu.com> 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