Re: Fetch digests explicitly for cryptohash with OpenSSL 3.0 and later

On Wed, Aug 05, 2026 at 01:09:13PM -0700, Mark Atwood wrote:
> cryptohash_openssl.c initializes the EVP_MD_CTX with the implicit static digest
> objects (EVP_sha256() and friends), which do not deterministically dispatch
> through a loaded provider. The patch fetches the digest by name, caches it in
> the context, and frees it on teardown, so hashing is served by the active
> provider. The digest type is fixed for the lifetime of the context, so the
> fetch is done once. The implicit path is kept for older OpenSSL and for
> LibreSSL, guarded by OPENSSL_VERSION_NUMBER >= 0x30000000L.
>
> The fetch uses the default library context and a NULL property query, so no
> dependency is added and no particular provider is required.

I was looking at this patch, and the switch to EVP_MD_fetch() makes
sense, based on this:
https://docs.openssl.org/3.0/man7/migration_guide/#programming

With this quote:
"If a library context is needed then all EVP_* digest functions that
return a const EVP_MD * such as EVP_sha256() should be replaced with a
call to EVP_MD_fetch(3). See "ALGORITHM FETCHING" in crypto(7)."

The code your agent has generated (because it's AI-generated) is not
really in line with the usual PostgreSQL format. The doc addition
does not bring much: the stance about MD5 and FIPS was already true:
we blocked MD5 computations in cryptohash_openssl.c before this
change, it's still the case after this change.

I have tested the attached with 3.5 (version installed on my system),
and some custom 3.0 and 1.1.1 (not interesting, legacy API) builds,
and that seems to work fine.
--
Michael