-
Notifications
You must be signed in to change notification settings - Fork 52
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
Cope with invalid hash algorithms in RECORD #179
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -192,13 +192,15 @@ def from_elements(cls, path: str, hash_: str, size: str) -> "RecordEntry": | |
if not path: | ||
issues.append("`path` cannot be empty") | ||
|
||
hash_value: Optional[Hash] = None | ||
if hash_: | ||
try: | ||
hash_value: Optional[Hash] = Hash.parse(hash_) | ||
hash_value = Hash.parse(hash_) | ||
if hash_value.name not in hashlib.algorithms_available: | ||
issues.append(f"invalid hash algorithm '{hash_value.name}'") | ||
hash_value = None | ||
Comment on lines
+198
to
+201
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be performing this validation in the validate method somehow, since this would prevent a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My thinking was that it's desirable to be unable to create a Yet another approach, doubling down on "invalid hash algorithms are invalid" would be to raise a |
||
except ValueError: | ||
issues.append("`hash` does not follow the required format") | ||
else: | ||
hash_value = None | ||
|
||
if size: | ||
try: | ||
|
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.
PEP 376 / https://packaging.python.org/en/latest/specifications/recording-installed-packages/ requires that RECORD must be in hashlib.algorithms_guaranteed, using _available is not good enough when producing installed databases in site-packages.
But the wheel format itself (https://packaging.python.org/en/latest/specifications/binary-distribution-format/) doesn't say anything one way or another about it...
So it disagrees with PEP 376 in at least two points:
And therefore the PEP cannot be taken as authoritative on algorithms_guaranteed. But only for wheels. Once e extracted it does need to be in _guaranteed.
Fun.
...
In theory this would solve the platform-conditional concern.
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.
It's not obvious to me what the intended availability of
installer.records
is. Can I use it to parse the RECORD in a wheel file, or one in site-packages? Is the appropriate guard here to enforce this when creating new RECORD files only?Experimental patch to validate this as part of destinations, where we know that any algorithm passed is definitely intended for creating a new installed RECORD file: 67da026.
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.
I'm not sure what conclusions, if any, you reach from the above.
I am therefore politely saying "noted"... but not doing anything about it!
Please say if you have opinions about how this MR ought to look (or submit an MR, I'm fine with this one being overtaken by something better)