-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
bpo-40645: use C implementation of HMAC #24920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Christian Heimes <[email protected]>
Lib/hmac.py
Outdated
_hashopenssl is not None and | ||
(digestname := _hashlib._digestmod_to_name(digestmod)) | ||
): | ||
self._init_hmac(key, msg, digestname) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes the assumption that if we have _hashopenssl
, all possible digests anyone could use will be available as part of openssl for use via its hmac implementation. I don't think that is necessarily true. A digestmod that supplies a string name can be supplied but not be something available in openssl.
presumably the easiest way around this while retaining the optimal openssl computation when possible is to catch an exception from _init_hmac
(due to _hashopenssl.hmac_new
raising) and fall back to _init_old
instead.
a test should be added to cover this case. (via a custom digestmod-like-object with a name and blocksize perhaps)
Lib/hmac.py
Outdated
_hashopenssl is not None and | ||
(digestname := _hashlib._digestmod_to_name(digest)) | ||
): | ||
return _hashopenssl.hmac_digest(key, msg, digestname) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fallback logic needed here as when digestname isn't supported by openssl.
When you're done making the requested changes, leave the comment: |
Thanks for the feedback, @gpshead! I'm not happy with the first draft. It's not elegant. It's easier to track builtin constructors in C and map them directly in |
Recognize _hashlib.openssl_sha256 function object as "sha256".
Seems that commit 933dfd7 introduced some reference leaks: commit 933dfd7
𓋹 ./python.exe -m test test_hashlib -R 3:3 == Tests result: FAILURE == 1 test failed: Total duration: 8.7 sec
Lib/hashlib.py | 1 + |
Opened #25063 to address it |
- [x] fix tests - [ ] add test scenarios for old/new code. Signed-off-by: Christian Heimes <[email protected]>
…, pythonGH-26079) This backports the feature and 2 subsequent bugfixes from: https://bugs.python.org/issue40645 Signed-off-by: Christian Heimes <[email protected]> Co-authored-by: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Pablo Galindo <[email protected]>
…, pythonGH-26079) This backports the feature and 2 subsequent bugfixes from: https://bugs.python.org/issue40645 Signed-off-by: Christian Heimes <[email protected]> Co-authored-by: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Pablo Galindo <[email protected]>
…, pythonGH-26079) This backports the feature and 2 subsequent bugfixes from: https://bugs.python.org/issue40645 Signed-off-by: Christian Heimes <[email protected]> Co-authored-by: Erlend Egeberg Aasland <[email protected]> Co-Authored-By: Pablo Galindo <[email protected]>
Signed-off-by: Christian Heimes [email protected]
https://bugs.python.org/issue40645
Automerge-Triggered-By: GH:tiran