Dealing with violations is necessary

[kornelski]

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 the set feature is used. There is a real safety violation there, but Linux projects or projects not using set 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, because safe-to-deploy is a built-in criterion, and I can't add implies 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 aforementioned hostname 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.

[mystor]

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.

[bholley]

A few other relevant notes:

• We've discussed some kind of implied-by for criteria to address the other deficiency you describe.
• We've also discussed sub-crate granularity for features, though it's a tricky space to get right.