gh-134531: cleanup _hashopenssl.c to support EVP_MAC#134626
gh-134531: cleanup _hashopenssl.c to support EVP_MAC#134626picnixz merged 17 commits intopython:mainfrom
_hashopenssl.c to support EVP_MAC#134626Conversation
This reverts commit 9d535ac.
|
🤖 New build scheduled with the buildbot fleet by @picnixz for commit 63bc38c 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F134626%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
|
I suggest adding a small news entry regardless, as this will land in a release branch it is nice to indicate to people reading the changelog where a name cleanup refactoring was done to the internals. |
Sure, I'll write a NEWS entry tomorrow and will merge this. |
|
Note: failures are related to GH. And if the backport fails to 3.13 due to conflicts, I'll ignore it as well (this liokely means I would anyway need to work harder :')) |
|
Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
…nGH-134626) Rename components related to `_hashlib.{HASH,HASHXOF}` objects. - The `EVPobject` structure is renamed `HASHobject`. - Non-clinic `HASH` methods are now prefixed by `_hashlib_HASH_*`. A similar change is made for non-clinic `HASHXOF` methods. - Functions extracting information from `EVP_MD` objects and functions constructing `EVP_MD` objects now include `openssl_evp_md` in their name. This change allows us to avoid future ambiguities between the `EVP_MD` and the `EVP_MAC` APIs (currently, we only use `EVP_MD` for hash functions and rely on the legacy interface for HMAC instead of using `EVP_MAC`). (cherry picked from commit cb8045e) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
Sorry, @picnixz, I could not cleanly backport this to |
|
GH-134703 is a backport of this pull request to the 3.14 branch. |
|
Ok let's have a look at the conflicts. |
|
Ok, forget it, the conflicts are too hard to fix because of UBSan failures that were fixed and clinic that was fixed differently. |
…n#134626) Rename components related to `_hashlib.{HASH,HASHXOF}` objects. - The `EVPobject` structure is renamed `HASHobject`. - Non-clinic `HASH` methods are now prefixed by `_hashlib_HASH_*`. A similar change is made for non-clinic `HASHXOF` methods. - Functions extracting information from `EVP_MD` objects and functions constructing `EVP_MD` objects now include `openssl_evp_md` in their name. This change allows us to avoid future ambiguities between the `EVP_MD` and the `EVP_MAC` APIs (currently, we only use `EVP_MD` for hash functions and rely on the legacy interface for HMAC instead of using `EVP_MAC`).
…n#134626) Rename components related to `_hashlib.{HASH,HASHXOF}` objects. - The `EVPobject` structure is renamed `HASHobject`. - Non-clinic `HASH` methods are now prefixed by `_hashlib_HASH_*`. A similar change is made for non-clinic `HASHXOF` methods. - Functions extracting information from `EVP_MD` objects and functions constructing `EVP_MD` objects now include `openssl_evp_md` in their name. This change allows us to avoid future ambiguities between the `EVP_MD` and the `EVP_MAC` APIs (currently, we only use `EVP_MD` for hash functions and rely on the legacy interface for HMAC instead of using `EVP_MAC`).
Previously, we used
EVPto denote anything related to hash functions. We didn't need to distinguish betweenEVP_MDandEVP_MAC. However, we will need to distinguish them and honestly, I always wanted to refactor this module.So, I decided to rewrite many function names. The logic is as follows:
_hashlib_HASH_*for HASH methods (previouslyEVPobject)_hashlib_HASHXOF_*for SHAKE methods (previouslyEVPXOF)EVPin function names when we're actually dealing with OpenSSL itself. It's confusing otherwise. On CPython's side, we're only wrapping an EVP_MD object, but we're not an EVP_MD object IMO. We are a HASH or a HASHXOF object since we export them as such.Note that we can backport this to 3.14, and, ideally, to 3.13 as well because if I were to fix a bug in 3.15, then we'll likely have conflicts if I were to backport the fix to 3.13.