More fine-grained control over ignoring specific issues to allow upstream crates to update
Is your feature request related to a problem? Please describe.
I have a transitive dependency on the Protobuf crate, which is currently affected by RUSTSEC-2024-0437
It is not likely that the upstreams (prometheus, opentelemetry-prometheus) will update the dependency in the next little while (as they are not directly vulnerable), but I would not want to "perma-ignore" the issue. As it is currently used by the upstream dependencies it seems to be harmless, but I wouldn't want it to be pulled in accidentally by some new code or dependency.
Describe the solution you'd like
I would like the ability to ignore the issue until the upstreams have had a chance to repair.
It would be nice if I could either
- ignore it when pulled in transitively by a specific dependency.
- or specify an "ignore until" date to the OWASP Dependency Check; see https://jeremylong.github.io/DependencyCheck/general/suppression.html or maybe better yet,
Currently I am adding something like this
ignore = [
{ id = "RUSTSEC-2024-0437", reason = "...(explanation)..." },
]
I would like to be able to add something like (the actual vulnerable crate is protobuf, but I only want to allow the prometheus and opentelemetry-prometheus to use the vulnerable version)
ignore = [
{ id = "RUSTSEC-2024-0437", reason = "...(explanation)...", from = "prometheus@..."},
{ id = "RUSTSEC-2024-0437", reason = "...(explanation)...", from = "opentelemetry-prometheus@..."},
]
and/or
ignore = [
{ id = "RUSTSEC-2024-0437", reason = "...(explanation)...", until="2025-04-11"}
]
Describe alternatives you've considered
I am currently just ignoring the issue, but that leaves the other other crates (transitive or not) open to accidentally pull in the vulnerable protobuf version in the future.
Additional context
I saw a similar issue was filed in https://github.com/EmbarkStudios/cargo-deny/issues/345 , but I think this use-case is different enough to warrant a separate issue (if only to document the reasons not to do it)
I am in the same situation and would like to support that request. Just ignoring advisories without a statement nearby that this is temporary does not inspire confidence. I don't see your use case to be all to different from #345, however. I also get the concern mentioned in #345: It would not be nice if CI builds were to start failing on a random date.
Therefore, I'd like to suggest an alternative to the until syntax proposed above: Let's link it to the crate version instead. This way, for every release, a maintainer has to review the cargo deny exceptions for CI to pass:
ignore = [
{ id = "RUSTSEC-2024-0437", reason = "...(explanation)...", while_version="<0.9.1" }
]
If a crate is maintained and does releases, at some point it will eventually hit the while_version and a reevaluation of that ignore statement. On the other hand, there is no impedance mismatch for normal development when that magic check date is passed.
Actually failing the CI with a reasonable message after the grace period is exactly what I want! But I also understand why others wouldn't want that :)