Re: BUG #19457: RE: pgp_sym_encrypt silently accepts non-FIPS ciphers (bf, cast5, 3des) when OpenSSL is in FIPS mod

From: Shishir Sharma <ansh01072001(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19457: RE: pgp_sym_encrypt silently accepts non-FIPS ciphers (bf, cast5, 3des) when OpenSSL is in FIPS mod
Date: 2026-04-25 06:08:50
Message-ID: CABV8eT1HBwmssr8=Xqp2Q65uN1=L=zuJK9hAgqc_gxnq7gaQcw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

My last message showed a failed delivery, so resending it.

> Daniel should have the last word on that, I guess, as it is his
> feature, but the semantics I have chosen are harder than that:
> - If the GUC is off, block everything.
> - If the GUC is on, allow everything.
> - If the GUC is fips, block the non-fips ciphers and allow the fips
> ciphers.
>
> This behavior would be more consistent and symmetric with the other
> functions, at least IMHO.

The intent behind gating the check on fips_allowed was that the GUC
(commit *035f99c*) was designed to block built-in crypto (gen_salt,
crypt) which use PostgreSQL's own implementations. PGP with AES goes
through OpenSSL's FIPS-validated EVP interface, so blocking it under
builtin_crypto_enabled=off felt like it went beyond what the GUC was
designed for.

That said, you and Daniel have far more context on the codebase and its
history than I do, so I'm happy to adjust or defer to whichever
approach you both prefer.

>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-04-25 07:27:28 BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
Previous Message Joe Conway 2026-04-25 00:23:45 Re: BUG #19457: RE: pgp_sym_encrypt silently accepts non-FIPS ciphers (bf, cast5, 3des) when OpenSSL is in FIPS mod