ci(hooks): replace the duplicated bootstrap with a thin stub - #72
Merged
Conversation
added 3 commits
August 18, 2026 20:18
The ~90 lines of fetch-validate-delegate logic move to vana-com/.github as scripts/bootstrap.sh (vana-com/.github#3). That duplication is where the worktree GIT_DIR bug and the GIT_CONFIG_GLOBAL origin-spoof hole both lived, and fixing them took six near-identical patches. What stays here is a stub that names the reviewed policy commit and fetches it. Fetching by SHA is self-authenticating, and the central bootstrap re-validates origin, SHA and cleanliness before anything executes. A future policy fix now reaches this repo when it advances its pin, with no edit to this file. The pin stays local deliberately — it is the supply-chain review gate. Assisted-by: AI
Review caught a real regression in the first version of this stub: it exec'd scripts/bootstrap.sh out of any pre-existing cache without checking it first, so a poisoned cache ran arbitrary code BEFORE the central validation it delegates to. Confirmed by planting a cache whose bootstrap printed and exited 0 — it executed. Validates symlink, origin, pinned SHA and cleanliness ahead of the exec, and refuses a symlinked bootstrap. These checks are deliberately duplicated with the central bootstrap: that one still re-runs them for callers arriving another way, but they must also happen here, before control transfers into the cache. Verified: the poisoned cache is now refused at the origin check and never executes, while fresh fetch, cached re-run and detection all still work. Assisted-by: AI
… cache Review caught that a poisoned cache can execute code through its own .git/config while being authenticated: core.fsmonitor runs a command during `git status`, so the cleanliness check was itself an execution vector. Environment scrubbing cannot reach this — the settings live in the cache's repo-local config, which only -c overrides neutralize. Pin moves to the policy carrying the same fix in bootstrap.sh, install-pre-push.sh and hooks/pre-push. Verified end to end: fresh install works, a planted core.fsmonitor never fires, a modified cache bootstrap is refused, and detection still exits 1. Assisted-by: AI
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.
Replaces this repository's copy of the EVM key-scan bootstrap with a thin stub, following vana-com/.github#3.
Why
Every consuming repository carried ~90 near-identical lines of fetch-validate-delegate logic. That duplication is where both recent bugs lived — the worktree
GIT_DIRfailure and theGIT_CONFIG_GLOBALorigin-spoof hole — and fixing them required six near-identical patches across six repos. It was the third time this logic had drifted between copies, and the narrowest copy was the exploitable one.What changes
The validation, locking and delegation logic now lives in
vana-com/.githubasscripts/bootstrap.sh. What stays here is a stub that does two things: name the reviewed policy commit, and fetch it.Fetching by SHA is self-authenticating — git verifies the delivered objects hash to the requested commit — and the central bootstrap re-validates origin, SHA and working-tree cleanliness before anything executes.
A future fix in the policy reaches this repository when it advances its pin, with no edit to this file.
What deliberately does not change
The pinned SHA stays here. It is the supply-chain review gate: without it the central repository could execute new code on every developer's machine at push time. The aim was never to remove the pin — it is one line — but to stop shipping ninety lines of logic alongside it.
Pin moves to
7f59130(vana-com/.github#3).Verification
Against the real published policy:
installin a clean repo fetches the policy, execs the central bootstrap, and installs the hookGIT_DIR, the policy cache is fetched and prepared correctlyattacker/evil.gitwhileGIT_CONFIG_GLOBALclaimsvana-com/.githubis refusedAssisted-by: AI