| 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.
>
| 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 |