feat(tcfeed): say that the workflow verifies the hash, not just the pin - #135
Merged
Conversation
The integrity check shipped in #134 and sh1pt#959. The request body never mentioned it, so the strongest supply-chain answer we have was invisible to the people who asked for it. That is not a cosmetic gap. Every decline on this workflow so far has been about the install, not the scanner: SonarCloud on githubactions:S8543, CodeRabbit scoring a request Moderate for handing an unpinned scanner a write-scoped job, and Haven's maintainer declining with whoever can publish that package can run code in this repository's CI from that point on, forever, without a further PR and naming the remedy exactly — "pinning to an exact version + integrity hash would address that specific objection". We now do both halves and were still describing only the first. The paragraph now says what actually happens: the tarball is downloaded, hashed, checked against a value committed in the workflow file, and not installed on a mismatch. It also gives the reader the command to check that value against the registry themselves, because a claim a reviewer can verify in one line is worth more than one they have to take on trust — which is the whole argument the paragraph is making. Does not touch the 45 requests already open. Their workflow files can be brought up to the current pack with `check --fix`; their bodies are prose in somebody else's notification feed and are left alone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan67 finding(s) HIGH/CRITICAL: 11 | MEDIUM: 55 | LOW: 1
…and 17 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
The integrity check shipped in #134 and profullstack/sh1pt#959. The request body never mentioned it — so the strongest supply-chain answer we have was invisible to exactly the people who asked for it.
That isn't cosmetic. Every decline on this workflow so far has been about the install, not the scanner:
githubactions:S8543We now do both halves and were still describing only the first.
What the paragraph says now
The verification command is deliberate: a claim a reviewer can check in one line is worth more than one they have to take on trust — which is the entire argument the paragraph is making.
Scope
Does not touch the 45 requests already open. Their workflow files can be brought up to the current pack with
check --fix; their bodies are prose sitting in somebody else's notification feed, and rewriting 45 of those is noise rather than a fix.Verified by rendering a dry run.
🤖 Generated with Claude Code