Skip to content
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

Open
hectorj2f opened this issue Oct 2, 2024 · 4 comments
Open

cargobump - detect ambiguous package matching #2

hectorj2f opened this issue Oct 2, 2024 · 4 comments
Assignees

Comments

@hectorj2f
Copy link
Member

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

@hectorj2f hectorj2f self-assigned this Oct 2, 2024
@roaksoax roaksoax changed the title Detect ambiguous package matching cargobump - detect ambiguous package matching Oct 28, 2024
@hectorj2f
Copy link
Member Author

related to: #3

@luhring
Copy link
Member

luhring commented Dec 9, 2024

I believe this is another instance of this:

wolfi-dev/os#36084

From the logs:

Error: failed to parse the pom file: failed to run cargo update 'error: There are multiple `rustls` packages in your project, and the specification `rustls` is ambiguous.

This results in the automation PRs adding cargobump steps that are bound to fail.

If we should track what I'm seeing in a different project/repo, just lmk and I'll move it there!

@mamccorm
Copy link

mamccorm commented Dec 9, 2024

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

@hectorj2f
Copy link
Member Author

what is the best practice when it comes to these use-cases? Is it safe to bump the oldest version in Cargo.lock file?

@mamccorm The best use case is to select the vulnerable dependency with the lower version.

Is it safe to bump the oldest version in Cargo.lock file?

Yes, I haven't found any instances when we needed to update both dependencies.

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants