gh-99108: Initial import of HACL-SHA3 into Python by msprotz · Pull Request #103597 · python/cpython (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation15 Commits15 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
I have a PR that's close to landing upstream (hacl-star/hacl-star#803). If there are any comments here, I'll be happy to tweak the PR upstream.
This replaces the in-tree SHA3 implementation for hashlib with a verified version from the HACL* project.
A few remarks:
- just like the original implementation, the HACL implementation uses a single API for all six Keccak variants
- I did not understand why there was a lock in sha3module.c, along with critical sections (ENTER_HASHLIB, etc.) when none of the other hashing modules have them -- I have removed this part
@gpshead please let me know what you think! I'm around, and can help make sure this gets into 3.12
I've refreshed this PR with a newer upstream.
- Eliminates an unused variable.
- Switches to a saner API of finish (SHA3) and squeeze (extra length argument, only for Shake).
@gpshead the upstream PR will land soon, let me know if there's anything I can do to help make sure this gets into 3.12!
I've landed the upstream PR, meaning that this is now pulling from HACL*'s main branch. I see from https://peps.python.org/pep-0693/ that the first 3.12 beta is in just a few days. I'll keep an eye on this PR in case any change or fixup is needed. Thanks!
🤖 New build scheduled with the buildbot fleet by @gpshead for commit b15b524 🤖
If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.
At first glance I believe this looks good, I'll get it in. I'm running it through the buildbots to see if anything unusual build-wise falls out to be addressed. (expect some flaky infrastructure or pre-existing issue noise among those results as well)
Thanks, so far only the refleaks test seems relevant -- it says hashlib leaked. Is there any way to get a trace of the allocations that weren't freed? Nothing jumps out at me looking at the code right now, and I don't believe anything was done differently compared to the other hashes (for which there were no leaks issues).
EDIT: used OSX's leaks tool in conjunction with MallocStackLogging, but I'm getting allocation traces from within the interpreter, which isn't super useful. I'll keep trying to figure this out, but of course any pointers are appreciated. Thanks.
EDIT2: tried tracing the calls to malloc performed within HACL, but the addresses don't seem to match what leaks tells me has leaked... maybe the leaked objects are Python objects?
I merged master in and I think I found the missing PyBuffer_Release. Can you run buildbot again?
🤖 New build scheduled with the buildbot fleet by @gpshead for commit 43f4ba7 🤖
If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.
This is the only error that shows up (WASI build):
ERROR: test_with_segments (test.test_pathlib.PathSubclassTest.test_with_segments)
ERROR: test_with_segments (test.test_pathlib.PathTest.test_with_segments)
ERROR: test_with_segments (test.test_pathlib.PosixPathTest.test_with_segments)
This doesn't seem to be related, does it?
@AA-Turner I pushed a commit to enforce better ordering.
I'm not sure how the list is ordered, though: from _abc.c to _weakref.c are files starting with an underscore, correctly sorted. Then, there is a mix of underscore-prefixed files and non-underscore-prefixed files, sorted alphabetically, after removing the initial underscore: arraymodule.c, ..., _operator.c, posixmodule.c, and so on.
I did my best to try to make the list look sensible. I hope this addresses your comments, let me know if it doesn't. Thanks!
@zooba would likely be the best to comment on what should be the case, though your changes seem alright to me -- thank you.
A
Great, thanks. I'm also happy to do a followup PR to fix things up after this one lands, if need be.
jbower-fb pushed a commit to jbower-fb/cpython that referenced this pull request
Replaces our built-in SHA3 implementation with a verified one from the HACL* project.
This implementation is used when OpenSSL does not provide SHA3 or is not present.
3.11 shiped with a very slow tiny sha3 implementation to get off of the <=3.10 reference implementation that wound up having serious bugs. This brings us back to a reasonably performing built-in implementation consistent with what we've just replaced our other guaranteed available standard hash algorithms with: code from the HACL* project.
Co-authored-by: Gregory P. Smith greg@krypto.org
carljm added a commit to carljm/cpython that referenced this pull request
carljm added a commit to carljm/cpython that referenced this pull request