Peter Eisentraut <peter@eisentraut.org> writes:
> On 05.10.23 22:55, Tom Lane wrote:
>> I found another bit of fun we'll need to deal with: on my F38
>> platform, pgcrypto/3des fails as attached. Some googling finds
>> this relevant info:
>> https://github.com/pyca/cryptography/issues/6875
>> That is, FIPS deprecation of 3DES is happening even as we speak.
>> So apparently we'll have little choice but to deal with two
>> different behaviors for that.
> I've been trying to get some VM set up with the right Red Hat
> environment to be able to reproduce the issues you reported. But
> somehow switching the OS into FIPS mode messes up the boot environment
> of the VM or something. So I haven't been able to make progress on this.
Hm. I was just using a native install on a microSD card for my
raspberry pi ...
> I suggest that if there are no other concerns, we proceed with the patch
> set as is for now.
After thinking about it for awhile, I guess I'm okay with only
bothering to provide expected-files for FIPS failures under OpenSSL
3.x (which is how your patch is set up, I believe). While there are
certainly still LTS platforms with 1.x, we don't have to consider FIPS
mode on them to be a supported case.
I'm more concerned about the 3DES situation. Fedora might be a bit
ahead of the curve here, but according to the link above, everybody is
supposed to be in compliance by the end of 2023. So I'd be inclined
to guess that the 3DES-is-rejected case is going to be mainstream
before v17 ships.
> The error message difference in the older OpenSSL version would probably
> need a small bit of coding. But we can leave that as a separate add-on
> project.
It's the *newer* version's message that I'm unhappy about ;-).
But I agree that that's not a reason to hold up applying what's
here. (In reality, people running FIPS mode are probably pretty
accustomed to seeing this error, so maybe it's not worth the
trouble to improve it.)
regards, tom lane
