@gpshead

Would you like to take a look at this PR?
The change will not affect to backward compatibility.

I guess there isn't much demand for hmac-sha3 yet. the other folks who might hit this probably have openssl builds without md5 or sha1?

It looks so, and the latter looks minor case in this era :)

Thanks @gpshead for reviewing and supplementing this PR!

Thanks @corona10 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

GH-103328 is a backport of this pull request to the 3.11 branch.

Thanks! somewhat surprised we hadn't run into this at work, but I guess there isn't much demand for hmac-sha3 yet. the other folks who might hit this probably have openssl builds without md5 or sha1?

SHA3 is fine since OpenSSL (at least in Python 3.11.2) provides it;

Python 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)] on win32
>>> import hmac
>>> hmac.digest(b'key', b'message', 'sha3_256').hex()
'0f43852a24d5597a8200312a95993991581679d63264f1b1ad4b5ccac7fe8ba4'

The only hash algorithms that were a problem are ones that OpenSSL doesn't provide via named lookup. So none of the built-in algorithms would trigger it as OpenSSL provides all of them (even whirlpool, mdc2, and the composite md5-sha1 work as expected) - that's why it took me (ab)using hashlib to find it. But patching hashlib (directly in the file or on the fly) to include a new algorithm does trigger it (as that's what I was doing). But you're right that if md5 or sha1 were removed from OpenSSL while still being kept in hashlib (e.g. with a stand-alone CPython implementation), then the problem would get triggered.

Not everyone's OpenSSL provides it. 1.1.1 and BoringSSL do not.