Thread: Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS

Hi all,

Trying to use OpenSSL with FIPS breaks if one attempts to call the
low-level SHA2 routines we currently use in sha2_openssl.c (upstream
calls that OpenSSLDie()), forcing a crash of PG.  The actual way to
fix that is to use EVP as I solved here:
https://commitfest.postgresql.org/30/2762/

Unfortunately, this enforces an ABI breakage so this is not
backpatchable material.  Now, if one attempts to use OpenSSL with
FIPS, the initialization of backup manifests in
InitializeBackupManifest() enforces a call to pg_sha256_init() for the
manifest file itself even if pg_basebackup, or anything requesting a
base backup with the replication protocol, does *not* want a backup
manifest.  One can for example enforce to not use a backup manifest
with --no-manifest in pg_basebackup, but even if you specify that base
backups cause the backend to crash on HEAD if using FIPS in OpenSSL.

Looking at the code, the checksum of the manifest file is updated or
finalized only if IsManifestEnabled() is satisfied, meaning that if
the caller does not want a manifest we do its initialization, but
we have no use for it.

Attached is a patch that I would like to back-patch down to v13 to
avoid this useless initialization, giving users the possibility to
take base backups with FIPS when not using a backup manifest.  Without
the solution in the first paragraph, you cannot make use of backup
manifests at all with OpenSSL+FIPS (one can still enforce the use of
the in-core SHA2 implementation even if building with OpenSSL), but at
least it gives an escape route with 13.

Thoughts?
--
Michael

On Tue, Nov 10, 2020 at 11:00:14AM +0900, Michael Paquier wrote:
> Attached is a patch that I would like to back-patch down to v13 to
> avoid this useless initialization, giving users the possibility to
> take base backups with FIPS when not using a backup manifest.  Without
> the solution in the first paragraph, you cannot make use of backup
> manifests at all with OpenSSL+FIPS (one can still enforce the use of
> the in-core SHA2 implementation even if building with OpenSSL), but at
> least it gives an escape route with 13.

Okay.  Hearing nothing, I have applied that.
--
Michael