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
