On Wed, Jan 05, 2022 at 01:08:53AM -0500, Tom Lane wrote: > I think it's very important that the error message in this case > mention "FIPS mode" explicitly. Otherwise, people will have no > idea that that's where the problem originates, and they'll be > frustrated and we'll get bug reports. (They may be frustrated > anyway, but it was their choice, or their corporate policy's > choice, to cut off their access to MD5. Not our place to dodge > that decision.) I am not completely sure how to detect that in 1.1.1 in the context of Fedora, and portability may become a tricky thing. FIPS_mode() and FIPS_mode_set() are legacy APIs that should not be used, and upstream just disables them in 1.1.1. [... digs a bit ...] Ugh. Fedora patches upstream's 1.1.1 to check and react on /proc/sys/crypto/fips_enabled. Their code is here, see particularly 0009-Add-Kernel-FIPS-mode-flag-support.patch: https://src.fedoraproject.org/rpms/openssl.git So that's why you are able to use it with 1.1.1. Well, we could do something similar to that, but in 3.0.0 things are done very differently: one has to set to alg_sect fips=yes with fips = fips_sect in the OpenSSL configuration to load the FIPS provider. Providing more error context is going to be hairy here.. In order to make things portable with 14 in cryptohash.c, we don't have any need to change the existing cryptohash APIs. We could just store in each implementation context a location to a static string, and add a new routine to extract it if there is an error, defaulting to OOM. -- Michael
Attachment:
signature.asc
Description: PGP signature
