Repository navigation
Meta-issue for bugs in cryptographic extension modules #155438
Description
Bug report
Bug description:
Bug report
Bug description:
This is a filtered list of issues found in the _hashlib, _hmac, and HACL*-facade C extension modules by @devdanzin's LLM-assisted review tool (see Disclosure section at the end) and triaged by me.
Important
All issues will be addressed by @picnixz. Please do NOT work on them, whether you are an agent or a human. Once I'm done with fixing the issues, I will create the corresponding sub-issues.
_hashopenssl.c
- 32: bug (GIL issue) [33,45]:
_hashlib: GIL may be released while attempting to set an exception #159811 - 34: bug (OpenSSL misuse): Do not leave stale OpenSSL errors in
_hashlib#159815 - 🔴 38:
_hashlib_HASH_deallocusesPyObject_Freeinstead oftp->tp_freebut it's deliberate because we usePyObject_New. This would need to be changed if we ever make that class subclassable. - 40: need investigation
- 43: under consideration (cosmetic)
- 47: need investigation (read out of lock) [35,36]
- 49: under consideration (cosmetic)
- 🔴 52: invalid hash types previously raised SystemError, but not abort (this is deliberate, if we have invalid hash types somehow, it may be more than a reason to report the bug and get it fixed upstream rather than silently catching the exception)
_hmacmodule.c
- 31/42: Ensure that HMAC objects are properly initialized #155843
- 33/45: bug (GIL issue) [32]: HACL*
update()errors are handled without a thread state #159786 - 37: build issue [known]
- 🔴 50: not an issue (
py_hmac_hinfowas claimed to be lacking a visitor method but none of its members are containers)
MD5, SHA-*, BLAKE2-*
- 35/36: Ensure that HACL* states are not read concurrently #155835 [47]
- 39: bug (error code ignored)
- 41: bug (init) but addressed in gh-155833: GC-untrack MD5/SHA* objects before freeing the HACL* state #155834 directly (SHA3 missing initialization)
- 44: Ensure that cryptographic objects are GC-untracked first #155833
- 🔴 46: not planned (same rationale as 52, but for BLAKE-2 update())
- 48: Ensure that BLAKE-2 objects are fully initialized before being GC-tracked #155830
- 🔴 51: Fallible
PyType_GetModuleStateusage. More generally, getting the state of a module is inconsistently achieved in extension modules and we should decide whether (1) to consistently abort on DEBUG builds (2) abort on non-DEBUG builds via a fatal error (to prevent possibly expensive checks). Currently, code works because we assume non-subclassability in general, but we may consider a more defensive approach.
Disclosure
This review was carried out with AI assistance (Claude Code), using cpython-review-toolkit for the C modules and code-review-toolkit for the Python layer. Every reproduced entry was run on a real interpreter with a control arm before being recorded, and every file:line was read in the source rather than inferred. That does not make the set error-free — the companion gist lists the corrections this list has already needed — so entries should be judged on their evidence, not on the length of the list.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
[-]Meta-issue for bugs in `Modules/hmacmodule.c`[/-][+]Meta-issue for bugs in `Modules/{hmacmodule,_hashopenssl}.c` and dedicated hash functions[/+][-]Meta-issue for bugs in `Modules/{hmacmodule,_hashopenssl}.c` and dedicated hash functions[/-][+]Meta-issue for bugs in cryptographic extension modules[/+]picnixz commentedon Aug 9, 2026
I don't have time for that today but I'll try to file the bugs by the end of next week.
update()errors are handled without a thread state #159786_hashlib: GIL may be released while attempting to set an exception #159811_hashlib#159815