implement imports.exclude

[bholley]

At present cargo-vet largely punts on conflict handling, we should define it.

Generally speaking, audits are additive and can't generate conflicts. However, it can happen if the range provided in a violation entry intersects a leaf in the audit version graph. This basically means that two parties explicitly disagree on whether the criteria are met for that version. Examples might include:

1. Somebody missed a problem when certifying an audit.
2. Somebody provided an overly-broad violation range.
3. Two parties fundamentally disagree on whether there's a problem.

I think (1) and (2) are the most likely cases, and so I think we want the default behavior to result in a discussion and ideally a consensus resolution. However, we can't have the tool entirely fall apart while that discussion is happening, or in the actual case of (3). So we need some mechanism to immediately resolve the conflict locally.

My spitball suggestion here is to add an exclude field to imports table entries, which lists a set of crates for which audits are dropped for that import. That strikes me as a lightweight mechanism to resolve conflicts in either direction (local violation + foreign certification, or vice versa), while also ensuring that any such conflict is surfaced for manual inspection.

@tmandry wdyt?

[Gankra]

I think I've been picturing a local override more as a flag only local audits can have with an extra flag for "and i mean it", ala !important in CSS, but maybe that's overly broad?

The flipside over-engineered version of this would be generating a uuid for each forbid entry so people can explicitly name it.

[bholley]

Yeah, my thinking was that being able to selectively reject imported audits as proposed above is a simple safety valve that doesn't complicate the model or lead to surprising results.

[tmandry]

One case where I could see fundamental disagreements cropping up are where we have unsafe code that is technically undefined behavior but also unlikely to ever be a problem. We come across this fairly often. (recent example)

In any case:

A problem I see with the model being proposed here is that a trusted upstream audit source can suddenly cause cargo vet to start failing without any changes, which is not nice if it's running in CI. Off the top of my head there are a few approaches I see that could work...

• Warn when there's a conflict, and ask the user to resolve it somehow to remove the warning, but don't fail
• Vendor upstream audits with a command that updates them periodically. These vendored files then become the source of truth until they are updated again.

[Gankra]

Yes there is already a "lockfile" for foreign audits -- imports.lock, one of the 3 files managed by cargo vet and which is already minimally implemented. It's just a cache of all the foreign files, nothing fancy.

The expected workflow is that CI will run with cargo vet --locked and therefore not update the lockfile at all. That said, because the stakes are a lot lower we currently always try to update the lockfile when cargo vet is run without --locked, unlike Cargo.lock, which tries to stay static more aggressively. This is presumably a good thing because you do want to know if one of your cohorts notices a serious issue and forbids something. It's just a question of what you do once you learn about that.

[bholley]

I added exclude to the book, morphing this issue to be about implementing.

[mystor]

I think this will be slightly easier to implement in a clean way once we've also fixed #238, as that way we can more easily track which source each imported entry comes from and do these exclusions locally after the lock has been updated.

I imagine we'll want to have the excluded entries downloaded and in the lockfile to keep formatting and error reporting anyway.