MIME-Version: 1.0
References: <19457-4bab15c17aea36c7@postgresql.org> <3A2299BC-1684-4CEB-BD65-1DEBFB446F24@yesql.se>
 <aervokmPnxlO6Oqs@paquier.xyz> <99F0B98C-2276-4C01-B553-BDD0806CAEEF@yesql.se>
 <1612210.1777041534@sss.pgh.pa.us> <71c66a3b-4c0d-447b-8b84-ef15ac047561@joeconway.com>
 <98BDEEAC-A401-41D8-B9C0-A1EBEBF2E08E@yesql.se> <aevvZLh_lYs-jo-s@paquier.xyz>
 <CABV8eT0YZzKmedQsYGP9AkHSK+rKr=rjUFrRQnFfeg1UsVKsXg@mail.gmail.com>
In-Reply-To: <CABV8eT0YZzKmedQsYGP9AkHSK+rKr=rjUFrRQnFfeg1UsVKsXg@mail.gmail.com>
From: Shishir Sharma <ansh01072001@gmail.com>
Date: Sat, 25 Apr 2026 11:38:50 +0530
Message-ID: <CABV8eT1HBwmssr8=Xqp2Q65uN1=L=zuJK9hAgqc_gxnq7gaQcw@mail.gmail.com>
Subject: Re: BUG #19457: RE: pgp_sym_encrypt silently accepts non-FIPS ciphers
 (bf, cast5, 3des) when OpenSSL is in FIPS mod
To: Michael Paquier <michael@paquier.xyz>
Cc: Daniel Gustafsson <daniel@yesql.se>, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d376dd065042b75d"
Archived-At: <https://www.postgresql.org/message-id/CABV8eT1HBwmssr8%3DXqp2Q65uN1%3DL%3DzuJK9hAgqc_gxnq7gaQcw%40mail.gmail.com>
Precedence: bulk

--000000000000d376dd065042b75d
Content-Type: text/plain; charset="UTF-8"

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.

>

--000000000000d376dd065042b75d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span class=3D"gmail-im">My last message =
showed a failed delivery, so resending it.<br><br>&gt; Daniel should have t=
he last word on that, I guess, as it is his<br>&gt; feature, but the semant=
ics I have chosen are harder than that:<br>&gt; - If the GUC is off, block =
everything.<br>&gt; - If the GUC is on, allow everything.<br>&gt; - If the =
GUC is fips, block the non-fips ciphers and allow the fips<br>&gt; ciphers.=
<br>&gt;<br>&gt; This behavior would be more consistent and symmetric with =
the other<br>&gt; functions, at least IMHO.<br><br></span>The intent behind=
 gating the check on fips_allowed was that the GUC<br>(commit=C2=A0<b>035f9=
9c</b>) was designed to block built-in crypto (gen_salt,<br>crypt) which us=
e PostgreSQL&#39;s own implementations. PGP with AES goes<br>through OpenSS=
L&#39;s FIPS-validated EVP interface, so blocking it under<br>builtin_crypt=
o_enabled=3Doff felt like it went beyond what the GUC was<br>designed for.<=
br><br>That said, you and Daniel have far more context on the codebase and =
its<br>history than I do, so I&#39;m happy to adjust or defer to whichever<=
br>approach you both=C2=A0prefer.</div><div class=3D"gmail_quote gmail_quot=
e_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">
</div>
</blockquote></div></div>

--000000000000d376dd065042b75d--