This patch seems to mitigate the issue. Not sure if this is the best approach, or if there's another place we should watch out for empty passwords when dealing with SCRAM-SHA-256 and FIPS.
Will raise an error when attempting to create a ROLE with a SCRAM-SHA-256 password:
CREATE ROLE "test-enc-pw" LOGIN ENCRYPTED PASSWORD 'SCRAM-SHA-256$4096:RlI0UDRNeEFSRUp0Y29kWA==$knE29fNkMKTvocaIou0vfZ+J+lwp4hawGKrXPVDOA08=:ZMQb8JU1qRdMv0wjFUBuD/E2G+YJhHV+KBSVzDC6ifA=';
Running on Postgres 125 BETA 3 gives more context into the error:
ERROR: could not compute server key: invalid key length
The "invalid key length" is returned from the FIPS Validated OpenSSL library Postgres is linked to. Where it is enforcing FIPS SP800-131 requirement for HMAC-SHA, minimum key size is 112 bits when used for security purposes.
Attaching a debugger, we can see that in normal code execution path, the plain_crypt_verify method should return STATUS_ERROR (because the password is not actually empty) then continue on it’s way to perform the actual encryption. But because we specify SCRAM-SHA we trigger scram_verify_plain_password: https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/libpq/crypt.c#L236-L239
Which causes it to error out, rather than returning a STATUS_ERROR like the working path(s).
There seems to be a conflict with how the NULL password is checked for, and enforcement of FIPS SP800-131 by a FIPS Validated OpenSSL library.