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

On Tue, Aug 11, 2026 at 01:33:26PM -0700, Mark Atwood wrote:
> 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.

As b91f79cd08ab and its code stand, I don't see a need for a change:
it does not change the fact that EVP_MD_fetch() is the recommended API
over the static routines in terms of 3.0. If something is wrong, we
still have a full release cycle to find defects. You are right that
the commit message is wrong regarding the loaded providers, though..
Now there is nothing that we can do to edit the commit message.

Something that bugs me a bit is if we should do something for
pgcrypto. We use EVP_get_digestbyname(), which is not marked as
deprecated, but it's still just a OBJ_name_get(), that maps to the
EVP_sha*() deprecated in 3.0. Perhaps there is little justification
to update this code, or perhaps something will be interested in that..

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

You're sounding like an agent to me here overall in all these
threads.. Sorry if I'm wrong, but writing messages with one's own
words is still a good practice overall, because one still needs to
understand the code he/she submits to be able to argue about it. An
agent is a tool that should not do that for you, even if it can be of
some help regarding some of its aspects.
--
Michael