cargo-deny icon indicating copy to clipboard operation
cargo-deny copied to clipboard

More fine-grained control over ignoring specific issues to allow upstream crates to update

Open gsson opened this issue 11 months ago • 2 comments

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)

gsson avatar Mar 11 '25 16:03 gsson

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.

naseschwarz avatar Mar 14 '25 18:03 naseschwarz

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 :)

gsson avatar Mar 14 '25 18:03 gsson