Exclude dev dependencies from cargo-deny

[cwfitzgerald]

Connections

Found in #8388

Description

This solves the active advisory for a dependency of winit. I'm not entirely 100% convinced this is the correct solution, but please discuss.

[cwfitzgerald]

This only happened if you counted winit

[kpreid]

I'm not entirely 100% convinced this is the correct solution, but please discuss.

Ideally, cargo-deny would distinguish “unmaintained” as less noteworthy. (Arguably, given how the system works overall, unmaintained advisories shouldn’t exist until they are handled better.) But, for the moment, this seems reasonable.

We might want to run the check including dev-deps but report the results in some way with less noise than failing PR CI. (It would also be nice to distinguish “malicious” (remove ASAP) from “buggy” (leave alone in dev-deps) and “unmaintained” (fix someday) advisories.)

[andyleiserson]

It would also be nice if this could be integrated with renovate somehow, and we could say "medium or low-severity, don't flag until renovate has had a chance to apply a fix on the regular schedule; high, out-of-cycle renovate PR and some short grace period to merge that PR; only reject in a way that fails CI if a renovate fix is not available by the applicable deadline.

(To contribute an opinion on the actual question, disabling for dev-dependencies seems fine to me if that's the best we can do with the available knobs.)

[cwfitzgerald]

Alright, then I think we should merge this, and see if we can improve the situation as some subsequent work

[ErichDonGubler]

This is one of the "other config. mechanisms" I was thinking about when we previously configured cargo-deny to ignore unpublished crates, so LGTM (after the fact), too!