feat(tcfeed): resolve the tarball hash alongside the version pin - #134
Merged
Merged
Conversation
The pack gained a threatcrushIntegrity input, which the workflow checks
before it installs anything. This fills it. Without this the render stops
with "the pack has an input tcfeed cannot fill", which is the guard doing
its job — but it means the two halves have to land together.
resolveIntegrity reads the registry's own dist.integrity for whatever
spec resolveSpec settled on, and is cached per spec for the same reason
the version is: one answer per run, so every request in a batch pins the
same bytes.
It fails in two different directions on purpose:
spec this resolved itself throw. The fallback is an unverified
install in a stranger's repository, which
is the thing being fixed.
spec the caller chose return empty. TCFEED_SPEC pointing at a
tarball or a local build has no
dist.integrity to read, and refusing to
render would break a legitimate use. The
pack treats empty as "no check" and warns
in the job log.
Anything that is not an SRI hash is treated as no hash. A half-read line
pinned into somebody's workflow fails their build closed on every run,
which is worse than not pinning one.
Verified against the updated pack:
resolved spec 0.11.0, hash sha512-EKcaxsgiydi7…hwWfQ==, matching
npm view dist.integrity exactly
rendered want='sha512-EKcaxsgi…' in the workflow, 0 placeholders left
TCFEED_SPEC ./some-local-build.tgz renders want='' and does not throw
strict a spec with no registry entry throws rather than shipping
an unverified install
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. |
ralyodio
added a commit
that referenced
this pull request
Aug 14, 2026
…in (#135) 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>
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.
Pairs with sh1pt's
threatcrush-scanpack change, which adds athreatcrushIntegrityinput the workflow checks before installing anything. This fills it.The two have to land together: without this, rendering the new pack stops with
the pack has an input tcfeed cannot fill— the guard doing its job.Why a hash and not just the pin
A version pin says which release to fetch. It does not say the bytes are the ones that release was published with, and the party answering "which version" is the party serving the bytes.
That's the line GlassOnTin drew on Haven#532 when they asked for "exact version + integrity hash" rather than accepting the pin as the answer. The exact version shipped a while back; the hash is the half that was still missing.
How it fails
Deliberately in two different directions:
TCFEED_SPECdist.integrity; refusing to render would break a legitimate use. The pack treats empty as "no check" and warns in the job logAnything that isn't an SRI hash is treated as no hash. A half-read line pinned into somebody's workflow fails their build closed on every run — worse than not pinning one.
Verification
Against the updated pack:
0.11.0, hashsha512-EKcaxsgi…hwWfQ==, matchingnpm view dist.integrityexactlywant='sha512-EKcaxsgi…'present in the workflow, 0 placeholders leftTCFEED_SPEC=./some-local-build.tgz— renderswant='', does not throw🤖 Generated with Claude Code