fix(supply-chain): trust protobuf-forensic-core as ours instead of exempting it - #5
Merged
Conversation
…empting it
ADR-0018 ranks the four cargo-vet mechanisms and states that reaching for a
weaker one is a defect. These crates are ours, consumed from crates.io, so
case 2 applies: a publisher-trust entry under h4x0r (user-id 347968), not an
exemption.
The distinction is semantic, not cosmetic. An exemption asserts "unreviewed,
accepted anyway"; a trust entry asserts "the publisher is ours". Recording our
own crates as unreviewed-but-tolerated misstated the supply-chain posture in
the direction of false comfort. A trust entry is also version-agnostic, so it
does not go stale on the next bump the way a pinned exemption does.
Exemption -> trust:
- protobuf-forensic-core
Verified (config change, so the vet run is the test):
Vetting Succeeded (13 fully audited, 53 exempted)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
h4x0r
force-pushed
the
fix/vet-trust-our-crates
branch
from
August 5, 2026 18:50
2a160c8 to
754f908
Compare
The `freshness` job is literally `cargo update --locked`: it fails when the committed lockfile trails what the manifests already permit. It was failing for exactly that reason -- the lock was three releases behind: clap 4.6.4 -> 4.6.6 clap_builder 4.6.2 -> 4.6.6 time 0.3.54 -> 0.3.55 Refreshed the lock and re-stated the cargo-vet exemptions for the three moved versions. This is bookkeeping, not a supply-chain decision: an exemption asserts "nobody audited this", which is equally true before and after a version bump. Verified the crate NAME set did not grow -- no dependency that was not already shipping is now shipping (indexmap dropped out; nothing new entered). Verification, all on this branch: cargo update --locked exit 0 (was 101) cargo test --workspace --all-features pass, 0 failed cargo deny check advisories/bans/licenses/sources ok cargo vet --locked Succeeded (14 audited, 52 exempted) CONTROL (proving the gate can still fail): restoring the previous Cargo.lock made `cargo update --locked` exit 101 again with "cannot update the lock file ... because --locked was passed"; re-applying the refreshed lock returned it to exit 0, and the restored file is byte-identical to the committed one. The gate is doing real work, not passing vacuously. Also commits supply-chain/imports.lock: refreshing the imported aggregate audit sets pulled in Google's indexmap audits, which is why indexmap could drop out of exemptions entirely -- a real human audit replacing a "nobody read this" placeholder. Verified this file is load-bearing rather than incidental: with the previous imports.lock, `cargo vet --locked` fails with "indexmap:2.14.0 missing [safe-to-deploy]"; with it, vetting succeeds.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
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
1 participant
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.
ADR-0018 ranks the four cargo-vet mechanisms and states that reaching for a
weaker one is a defect. These crates are ours, consumed from crates.io, so
case 2 applies: a publisher-trust entry under h4x0r (user-id 347968), not an
exemption.
The distinction is semantic, not cosmetic. An exemption asserts "unreviewed,
accepted anyway"; a trust entry asserts "the publisher is ours". Recording our
own crates as unreviewed-but-tolerated misstated the supply-chain posture in
the direction of false comfort. A trust entry is also version-agnostic, so it
does not go stale on the next bump the way a pinned exemption does.
Exemption -> trust:
Verified (config change, so the vet run is the test):
🤖 Generated with Claude Code