On Wed, Aug 05, 2026 at 01:09:11PM -0700, Mark Atwood wrote: > The legacy HMAC_CTX interface (HMAC_CTX_new, HMAC_Init_ex, HMAC_Update, > HMAC_Final) has been deprecated since 3.0, and it does not dispatch through > the > provider framework, so a loaded provider's HMAC implementation is bypassed. > The patch fetches "HMAC" with EVP_MAC_fetch(), creates an EVP_MAC_CTX, and > selects the digest through an OSSL_PARAM. The HMAC_CTX path is retained 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; the provider is > selected by the usual OpenSSL configuration (openssl.cnf).
This patch was not that bad. The amount of code duplicated in pg_hmac_create() for the error handling was just there for EVP_MAC_free(), so I have added an extra #ifdef for it before throwing an error on OOM. OSSL_PARAM_construct_utf8_string() has a couple of alternatives, like using a pointer. Now, looking at the code and some demo code, mainly hmac-sha512.c in upstream, that's the right alternative. The change in pg_hmac_final() was shaped weirdly, tweaked it to make it more consistent. And after testing that across various OpenSSL versions down to 1.1.1, the result was OK, so applied on HEAD. Now that's two. Still need to look at the channel binding piece. -- Michael
signature.asc
Description: PGP signature
