-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Validate VCS urls in hash-checking mode using their commit hashes #11968
base: main
Are you sure you want to change the base?
Conversation
The default is potentially dangerous.
raise VcsHashUnsupported() | ||
if not req.user_supplied: | ||
raise DependencyVcsHashNotSupported() | ||
return VcsHashes() | ||
if req.link.is_existing_dir(): | ||
raise DirectoryUrlHashUnsupported() |
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.
Note to self: when req.is_wheel_from_cache
is True, link is the cached wheel and not the link to the artifact that was downloaded to build the wheel. So this function may not necessarily do what one expects when reasoning on req.link.
51173ff
to
b5608e7
Compare
b5608e7
to
a1cd61b
Compare
elif isinstance(req.download_info.info, VcsInfo): | ||
if not req.user_supplied: | ||
raise DependencyVcsHashNotSupported() |
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 wonder if this would break anything. How can this branch be reached?
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 would raise in require-hashes mode only, if you have a dependency as a git direct URL that is obtained from cache.
I think these should not be considered hash-valid unless the commit hash has been provided by the user, either as a requirement file or a constraint.
This PR still needs work. Next step is adding a lot of test coverage. Then possibly some refactoring.
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.
If an immutable VCS URL is both user-supplied and a dependency, would this cause the latter specifier break installation?
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 should not, because when the dependency is examined by the resolver it is "merged" with the user-supplied one? That's definitely a test case to consider.
|
||
pass |
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.
pass |
This is still on my list but unfortunately I won't have time to finish it in time for 23.2. |
I removed #6469 from the 23.2 milestone for consistency. |
This PR seemed to work for me, for installing a package from a git repo. |
Is there anything we can do to move this forward? It seems to work. Thanks! |
Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: Ed Morley <[email protected]>
Tests to do
|
@sbidoul Here's a test for the second and third points you mentioned. Is that helpful? Should I work on expanding it more?
|
Any way we can help this PR move forward @sbidoul ? |
closes #6469