-
Notifications
You must be signed in to change notification settings - Fork 3
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
cargobump - detect ambiguous package matching #2
Comments
related to: #3 |
I believe this is another instance of this: From the logs:
This results in the automation PRs adding If we should track what I'm seeing in a different project/repo, just lmk and I'll move it there! |
Hey @hectorj2f - besides the suggested enhancements to cargo/bump here, what is the best practice when it comes to these use-cases? Is it safe to bump the oldest version in Cargo.lock file? If there are multiple versions defined then i'd assume there is a reason for this (intended), and bumping will cause issues. If not, then we can draft a process for patching in absence of this fix / enhancement |
@mamccorm The best use case is to select the vulnerable dependency with the lower version.
Yes, I haven't found any instances when we needed to update both dependencies.
Generally it should work when bumping the lower version to a non-vulnerable one. However, it is common to find situations when it is not possible to upgrade the version, and thus mark these CVEs as pending-upstream-fix. |
It could happen that we have the same package with different version in the same Cargo.lock file. We need to detect the older and attempt to bump it to the non-vulnerable version.
e.g. https://github.com/wolfi-dev/os/pull/29876/files#diff-f0ef7284b84894411029f23dec21b84b1b872d273302ff36c76ec0b68990096a
The text was updated successfully, but these errors were encountered: