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

Correction: my rationale for this patch was wrong, and so was the probe I
attached.

Implicit static digests DO reach providers. evp_md_init_internal() sees
type->prov == NULL and re-fetches the MD by name, so EVP_sha256() passed to
EVP_DigestInit_ex ends up provider-backed. My probe missed that because
EVP_MD_CTX_get0_md() returns ctx->reqdigest, the MD passed in, not the one
used. Please disregard provider_probe.c.

The corrected probe is attached. With the default property query set to
provider=legacy, which has no SHA256, EVP_DigestInit_ex(ctx, EVP_sha256())
fails. It could not if that path were served by a built-in.

So this patch is not a bypass fix. What survives: the internal fetch
hardcodes libctx=NULL and propq="", so a non-default OSSL_LIB_CTX gets no
provider control and no property query is expressible, and a registered ENGINE
takes the legacy branch and bypasses providers outright. Control and clarity,
not bypass.

Patch 1 (HMAC via EVP_MAC) is unaffected. HMAC_CTX does the ipad/opad
construction in OpenSSL's own code and delegates only the digest, so a
provider's HMAC is genuinely never consulted.

Repost on the narrower basis, or withdraw? The same correction applies to the
channel binding patch [1].

[1] https://postgr.es/m/178596055550.1584328.5465570319340175126%40reviewcommit.com

--
Mark