fix(supply-chain): trust safe-read as ours instead of exempting it - #14
Merged
Conversation
safe-read is ours, published to crates.io by h4x0r, so ADR-0018 mechanism (2)
applies: a trust entry keyed on the publisher. This store carried mechanism (4)
instead — an [[exemptions]] block pinned to the exact version in the lockfile.
That pin is why this keeps recurring. An exemption names one version, so the
moment safe-read publishes again every consumer holding one goes red at once,
for no reason connected to the code. It already happened this sweep: publishing
safe-read 0.2.1 reddened dmg, aff4, ewf, journald and disk-forensic
simultaneously, each reporting
safe-read:0.2.1 missing ["safe-to-deploy"]
This repo is green today only because its exemption still matches its lock. It
is queued to fail the same way on the next bump, so the fix is applied here
before that happens rather than after — 18 repos share the pattern.
A trust entry records the publisher rather than the version and survives the
bump.
Verified by making it fail on purpose, not by reading the green: with the trust
entry removed `cargo vet --locked` names safe-read as unvetted, and with it
restored the run succeeds. The control matters because these stores carry many
unrelated exemptions, and a green run over those alone would say nothing about
this crate.
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.
safe-read is ours, published to crates.io by h4x0r, so ADR-0018 mechanism (2)
applies: a trust entry keyed on the publisher. This store carried mechanism (4)
instead — an [[exemptions]] block pinned to the exact version in the lockfile.
That pin is why this keeps recurring. An exemption names one version, so the
moment safe-read publishes again every consumer holding one goes red at once,
for no reason connected to the code. It already happened this sweep: publishing
safe-read 0.2.1 reddened dmg, aff4, ewf, journald and disk-forensic
simultaneously, each reporting
This repo is green today only because its exemption still matches its lock. It
is queued to fail the same way on the next bump, so the fix is applied here
before that happens rather than after — 18 repos share the pattern.
A trust entry records the publisher rather than the version and survives the
bump.
Verified by making it fail on purpose, not by reading the green: with the trust
entry removed
cargo vet --lockednames safe-read as unvetted, and with itrestored the run succeeds. The control matters because these stores carry many
unrelated exemptions, and a green run over those alone would say nothing about
this crate.