Open kornelski opened 11 months ago
Our story around violations is unfortunately one of the weaker ones in cargo-vet, just due to the use-cases being less developed due to relatively infrequent use. I can definitely see us wanting to add something more in this area in the future.
That being said it is currently possible for you to locally resolve a dispute like this one from within your own supply chain by adding the crate in question to the violation source's exclude
list in your config.toml
(https://mozilla.github.io/cargo-vet/config.html#exclude) - this will prevent all audits and violations for the crate from being imported from that source.
I know cargo-vet deliberately avoids having overrides for
violation
, but this causes problems that make adoption of cargo-vet difficult.Lack of conditional audits
For example, the
hostname
crate has a memory-safety bug, but only on Windows, and only if theset
feature is used. There is a real safety violation there, but Linux projects or projects not usingset
are not affected.cargo-vet doesn't have per-platform, per-feature, per-function audits, so I can't express the real safety situation of this crate. I have a choice of making a technically false audit saying the crate is safe, or audit it as a violation, and cause a headache for projects that are not affected. I don't think custom criteria help here. I can't switch to using something like
safe-to-deploy-only-on-linux
, becausesafe-to-deploy
is a built-in criterion, and I can't addimplies
to it.Distributed audits are at odds with coordinated audits
The second problem is that audit conflicts are fatal errors. cargo-vet says to just talk to the audit author, but if I use audits from the registry, I'd need to chase people from external companies.
This is highly problematic when I use
cargo vet
in my CI as a blocking check. I really want to reuse other people's audits, because otherwise auditing is too much work. But I can't be dependent on someone else, in another company, in another timezone, updating their audit for me. They may not even agree to change their audit, since there can be contentious cases like the aforementionedhostname
crate.So I really miss having a feature to say "I've reviewed this audit/violation, and I think it's OK to ignore it for this project". As a precaution, it could have an expiry date to force a periodic re-review of such overrides.