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
