Peter Eisentraut <pe...@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