EmbarkStudios
Ignore sec-advisories for some crate until a given date
Bytecode Alliance folks have ran into an interesting use case: a low-urgency sec-advisory that is fine to ignore for some time, but that should be re-reviewed some time later: https://github.com/bytecodealliance/wasmtime/pull/2881. To not forget about it, it'd be nice that cargo-deny can "ping back" after a given date, while ignoring the issue until the given date. Is that something that would make sense to add in cargo-deny?
(There's the question of which time zone should be applied to such a date, but any would work, really; I don't expect that being a day early or late in this kind of situation would be dramatic.)
There is a date on the advisories, so think would technically be possible to ignore advisories of certain categories that are "X days new" and then fail or warn on them. Or maybe only warn on new such advisories, and error on them after that deadline, depending on how you configure it.
Though would assume you have a separate pipeline or information to be notified about new advisories so you can try and fix them before this error case happens X days later.
In our use case of cargo-deny we had to disable errors on some of the umaintained crate warnings due to them being low-urgency and shouldn't block builds, and instead just warn on it which prints out in logs and when running it locally. Think that been working pretty ok for us but can happen that one forgets about an advisory about unmaintained crate, but don't think I want to go back to that failing (essentially random) builds either.
but don't think I want to go back to that failing (essentially random) builds either.
That's a good point. Maybe that's a different feature request, but it'd be nice if there was a way to run the sec-advisories checks only with a certain cargo deny runtime flag; then users could use Github period jobs (cron-like) to just run the sec-advisories checks, separate from the rest of the Cargo deny checks. This way, the sec-advisories checks wouldn't happen in random builds, but in separate instances.
This is already supported, cargo deny check by default will run all checks, but you can specify which checks to run, eg cargo deny --all-features check advisories
As mentioned there is already a way to get this behavior without changes to cargo-deny.