Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS - Mailing list pgsql-hackers

From Michael Paquier
Subject Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS
Date
Msg-id 20201110020014.GE1887@paquier.xyz
Whole thread Raw
Responses Re: Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Next
From: Alvaro Herrera
Date:
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait