Workflow for replacing trusted publisher with imported audit?

[repi]

Hi, have a question about how the trusted publisher workflow works and how best to replace it over time with proper audits.

Concrete example:

1. We had a few crates that we hadn't audited, but they were developed by a developer we know and trust so we added them as a trusted publisher which created trust records for it in our repo.
2. Then after we have audited the dependency and added it to our public global registry of audits (in Audit android-activity v0.4.1 EmbarkStudios/rust-ecosystem#94) that we (and others) import into their repositories.
3. Then when we update our repositories and import audits with cargo vet regenerate imports, I expected this new audit to have been imported and replace the trusted publisher of that specific crate, but this did not happen.
4. If we manually remove the trusted publisher record of the crate, then import/regen audits, the new audit gets imported properly.

Is this the intended explicit workflow? Or is something missing here with this quite new (but excellent) functionality with trusted publishers?

Doing this manually seems a bit cumbersome and error prone as hard to see that an audit is now available instead, which I believe should have taken precedence over a trusted publisher as it is much more valuable, and not time limited.

[bholley]

Currently, cargo-vet prioritizes what's in audits.toml, and tries to minimize the set of imported entries.

I think one could make a case that an imported audit is better than a local trust entry, but I'm not yet convinced it's better enough to warrant re-architecting the import mechanics to add those audits to imports.lock. Unlike exemptions there's no expectation that users should be trying to get rid of their trusted entries, so I'm not sure what the practical user benefit would be.

Regarding the date range: it's worth emphasizing that this applies to publication date rather than current date. So if version x.y.z is published within the range of a trusted entry, that entry is just as permanent as an explicit audit for x.y.z.

[repi]

ah interesting, one can definitely see it from that direction with trusted entries taking precedent over audits, which does indeed keep the list of import audits cleaner and can reduce noise if there are a bunch of publishers one really trusts.

though in this direction, it feels like it can still be nice to somehow be able to see that it does exist audits even for crates published from trusted sources. though probably not in cargo suggest as it is no longer there.

for example we have some devs in our team that we definitely trust and that have independently built and published crates that we do use, and while we trust them we would much rather have an audit of the specific crates (from us or from others), and that would help others using those crates as well.

for now I guess we can manually continue to remove the trusted published crate listings and import audits, but it is a bit of a discoverability problem if using trusted publishers more widely (like for example both us and Firefox does us it for some long time well establish Rust devs that have built a lot of crates).

[bholley]

Yeah — it's definitely better for the ecosystem to have audits rather than trusted entries, because they can be automatically imported by others (whereas trusted entries can only be suggested). I'd figured most projects would lack motivation to generate audits for things they already trust, but if this is of interest to Embark, we could consider adding something like an --ignore-trusted flag to cargo vet suggest to make it easier to identify the audit gaps.