chore(supply-chain): commit the imported audits the gate is already relying on - #117
Merged
Conversation
… on main again `cargo vet` fails on `main` today, and has since `serde_json` and `thiserror` were bumped: five dependencies — anyhow, serde_json, syn, thiserror, thiserror-impl — report as unvetted. A blocking gate that is red on the default branch stops discriminating: every PR inherits the same failure, so the check says nothing about the change under review, and the seven open dependency bumps look blocked by their own contents when they are not. Nothing here records new trust. The audits already exist and are already imported by name in `config.toml` — Mozilla, Bytecode Alliance and Google, each signed by a person, plus dtolnay's publisher entries — and were simply published after this lockfile was last written. Refreshing it is what `cargo vet` does on every run; the file had drifted behind. That leaves each bump needing only its own crate version, which is the question it should have been asking all along.
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
msalvatti
changed the title
Without `--locked`, `cargo vet` refetches the import sets on every run. The gate then answers a question about what upstream happened to publish that minute rather than about what this repository recorded and reviewed — and it gives a different answer offline than online. That is not hypothetical here: the committed `imports.lock` is five dependencies behind, `cargo vet --locked` fails on it, and CI passes anyway because Mozilla, Bytecode Alliance and Google published the missing audits between 18 and 22 July. The same bumps failed this gate on 1 August, before those audits existed. Nothing in the repository changed in between. With the lockfile refreshed in the commit before this one, `--locked` reports Vetting Succeeded. Refreshing is now something a PR does deliberately, showing the diff of whose audits are being relied on, rather than something every CI run does silently.
This was referenced Aug 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Correcting my own framing: I opened this saying
cargo vetfails onmain. It does not —main's supply-chain check passed at 13:54 today. What fails iscargo vet --locked, and the difference is the point.supply-chain/imports.lockis stale. Five dependencies —anyhow,serde_json,syn,thiserror,thiserror-impl— are not covered by the audits it records:CI runs
cargo vetwithout--locked(ci.yml:221), so it fetches the import sets fresh on every run and passes — because Mozilla, Bytecode Alliance and Google published those audits between 2026-07-18 and 2026-07-22, after this lockfile was last written. The bump PRs that failed this gate on Aug 1 were failing partly on this, before those audits existed upstream.So the gate currently answers a question about what upstream happens to have published at the moment CI runs, not about what this repository has recorded and reviewed. That is what
imports.lockexists to prevent: a supply-chain decision should not change under you because someone else's file did, and it should give the same answer offline as online.No new trust is recorded. Every entry comes from a source
config.tomlalready imports by name, signed by a person — Mike Hommey and Jan-Erik Rediger (Mozilla), Pat Hickey (Bytecode Alliance), ChromeOS (Google) — plus dtolnay publisher records. Committing them is whatcargo vetwrites on any normal run.After this,
cargo vet --lockedreports Vetting Succeeded (148 fully audited, 19 partially audited, 198 exempted), and each open bump is left needing only its own crate version — which is the question that gate should be asking:redis:1.5.0http:1.5.0tokio:1.53.1time:0.3.54,time-macros:0.2.32serde,serde_core,serde_deriveasync-trait:0.1.91http-body-util:0.1.4Those seven are a separate decision — exempt, audit the diffs, or wait for the upstream sets to catch up, which is what just happened for the five above.
cargo denyandcargo auditpass on all of them, so none carries a known advisory.