fix: make the pre-push key scan usable from worktrees and on macOS

[maciejwitowski]

The optional EVM key scan could not run at all in two common setups. Both fail closed, so nothing was exposed — but a hook that cannot be installed, or cannot pass, is a hook developers route around with --no-verify. That is the outcome this policy exists to prevent.

1. Git worktrees

Git exports GIT_DIR into hook processes. In a linked worktree that value is an absolute path, so git -C "$shared_dir" ... still resolves against the pushing repository: the hook read the repo's HEAD, origin and status instead of the pinned policy checkout's, and refused with Vana scanner checkout is at <repo HEAD>, expected <policy SHA>. In a normal checkout GIT_DIR is the relative .git, which happens to resolve correctly under -C — which is why this only bites worktrees.

Adds a shared_git helper that scrubs the inherited repository environment and routes every command that must target the policy checkout through it, in both hooks/pre-push and scripts/install-pre-push.sh. Commands that scan the pushing repository keep the inherited environment, which is what they want.

The scrub list is taken from git rev-parse --local-env-vars rather than hardcoded, plus the GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM/GIT_CONFIG_NOSYSTEM overrides that are not in that list, with a hardcoded fallback for a git too old to answer.

Why the config vars matter. git -c remote.origin.url=... push exports GIT_CONFIG_PARAMETERS into hooks. Scrubbing only the directory variables fixes the worktree bug but makes the origin integrity check satisfiable from the caller's environment rather than the checkout's real config. That is not reachable on main today — the GIT_DIR bug masks it by failing at the SHA check first — so it is a hole this fix would have opened had it stopped at the directory variables. Verified both ways, see below.

2. macOS checksum verification

macOS ships its own /sbin/sha256sum (sha256sum (Darwin) 1.0). It rejects the GNU long options used in install-gitleaks.sh, so command -v sha256sum succeeded, the GNU branch was taken, and the download check failed for every download regardless of authenticity — the shasum fallback was never reachable on the one platform that needed it. install-pre-push.sh prepare therefore died on usage: sha256sum [-bctwz] and the hook could never be installed.

Prefers shasum -a 256, which accepts --check/--status on both platforms, keeping sha256sum for minimal images that ship coreutils but no perl.

Note verify-gitleaks.sh is deliberately untouched: its plain sha256sum "$file" produces byte-identical <hash> <path> output on Darwin and GNU, so there is no bug there.

Verification

On macOS with a stock PATH (no Homebrew coreutils), against a scratch policy cache:

• install-pre-push.sh prepare completes; previously it died on the sha256sum usage error
• the hook runs from a linked worktree with GIT_DIR set and exits 0 on a clean range; previously it refused before scanning anything
• detection is unchanged — the same hook still exits 1 and reports Potential EVM private key detected on a range containing one
• shasum -a 256 --check --status was checked to exit 0 on a matching digest and 1 on a mismatch, so verification is still real
• spoof test: with the policy cache's origin set to https://github.com/attacker/evil.git and GIT_CONFIG_PARAMETERS/GIT_CONFIG_COUNT set to claim vana-com/.github, this branch refuses at the origin check. A directory-variables-only scrub accepted it and proceeded.

Downstream

vana-sdk pins this repo by SHA (CENTRAL_POLICY_SHA in .github/scripts/install-evm-key-scan-hook.sh) and has the same GIT_DIR bug in its own bootstrap — fixed in vana-com/vana-sdk#189. That PR needs its pinned SHA bumped to this merge commit before the fix takes effect end to end.

🤖 Generated with Claude Code