Repository navigation
verify-action-build: recognize fileSHA256()-style file-hash helpers as verification - #1001
Merged
Merged
Conversation
…s verification
opentofu/setup-opentofu's `lib/setup-tofu.js` downloads the CLI zip via
`tc.downloadTool()` and then validates it:
const checksum = await fileSHA256(pathToCLIZip);
if (!checksums.includes(checksum)) throw new Error(...); // SHA256SUMS
`fileSHA256` is imported from the sibling `lib/util.js`, where the actual
`createHash('sha256')` body lives. Within the downloader file the only
verification evidence is the `fileSHA256(...)` call name — but none of the
`_JS_VERIFICATION_PATTERNS` matched that shape, so the v2.0.1 -> v2.0.2 bump
(#980) was false-flagged as an unverified download and the `verify` job failed.
This is the same class as the astral-sh/setup-uv `validateChecksum()` fix
(#910/#916): the hashing implementation lives in a sibling module and the
call name is the surviving in-file evidence.
Add a pattern that recognizes a helper call whose name contains an explicit
SHA algorithm (`fileSHA256(`, `getSHA512(`, `sha256File(`, ...). It stays
tight enough not to match `createHash('sha256')` (the paren precedes the
algorithm there) or non-SHA hashes. Covered by two regression tests: the bare
helper-name family and a faithful trim of the real opentofu download->verify
sequence.
Generated-by: Claude Code (Opus 4.8)
Member
Author
|
Gentle ping @ppkarwasz @dfoulks1 -- small verify-action-build enhancement here (recognizes |
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.
Problem
The
verifyjob on #980 (opentofu/setup-opentofu v2.0.1 → v2.0.2) fails with:But the action does verify.
lib/setup-tofu.jsdownloads the CLI zip and then:fileSHA256is imported from the siblinglib/util.js, where the actualcreateHash('sha256')body lives, andresolveChecksums()falls back to therelease's published
SHA256SUMS. Within the downloader file the onlyverification evidence is the
fileSHA256(...)call name — which no_JS_VERIFICATION_PATTERNmatched. So this is a false positive (case E), not areal gap.
This is the same shape as the astral-sh/setup-uv
validateChecksum()fix(#910/#916): the hashing implementation lives in a sibling module and the call
name is the surviving in-file evidence.
Fix
Add one pattern recognizing a helper call whose name contains an explicit SHA
algorithm (
fileSHA256(,getSHA512(,sha256File(, …). It stays tight enoughnot to match
createHash('sha256')(the paren precedes the algorithm there) ornon-SHA hashes.
Two regression tests: the bare helper-name family, and a faithful trim of the
real opentofu download→verify sequence.
Verification
uv run pytest utils/tests/→ 294 passedprek runon the changed files → cleanOnce merged, #980 (and future opentofu/setup-opentofu bumps) verify cleanly.
🤖 Generated with Claude Code