Skip to content

fix(security): resolve hook dir via git + assert install landed (audit 2e-02)#51

Open
runyourempire wants to merge 1 commit into
mainfrom
fix/gate-hookdir-resolve
Open

fix(security): resolve hook dir via git + assert install landed (audit 2e-02)#51
runyourempire wants to merge 1 commit into
mainfrom
fix/gate-hookdir-resolve

Conversation

@runyourempire

Copy link
Copy Markdown
Collaborator

Closes GPT-5.5 re-audit finding 2e-02 — the follow-on to 2e-01.

The issue

install-gate.sh hand-parsed core.hooksPath with case $cur in [A-Za-z]:*) HOOKDIR=$cur, using a Windows-native absolute path (backslashes) verbatim in bash. That relies on MSYS backslash-path translation, which is not portable across bash-on-Windows variants — in some setups it lands the hardened hook where git never reads it while the OLD ungated hook stays active: a false "installed" that leaves the 2e-01 RCE open.

Honest note: the specific mangling did not reproduce under this box's Git Bash (the path translated correctly both ways in two repro variants), but the dependency is real and environment-specific, so it's removed rather than argued.

The fix

  1. Resolve the hooks dir the way git doesgit rev-parse --path-format=absolute --git-path hooks — which honors core.hooksPath and returns an absolute forward-slash path usable in every bash-on-Windows variant. We now write exactly where git reads; misplacement is removed by construction (git<2.31 fallback normalizes via cygpath/tr).
  2. Post-install assertion — after writing, confirm the gate block is present at git's resolved active hook path; if not, print ERROR and exit 1 instead of reporting success. A misplaced write can no longer masquerade as a protective install.

Verified (4 configs)

default → .git/hooks; Windows-native backslash core.hooksPath → lands at git's resolved path; custom relative dir → chains, re-run refreshes to a single block (idempotent migration from the old installed gate); a forced misplaced write → ERROR + exit 1.

Same scope caveat as #50: .githooks/, .verax/, tools/ ship in no published crate — no released artifact affected.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CsePmfHDMBKRNDLNb3TLD5

…e audit 2e-02

GPT-5.5 re-audit finding 2e-02 (follow-on to 2e-01). The installer hand-parsed
core.hooksPath with 'case $cur in [A-Za-z]:*) HOOKDIR=$cur', using a Windows-native
absolute path (backslashes) verbatim in bash. That depends on MSYS backslash-path
translation, which is not portable across bash-on-Windows variants — in some setups it
lands the hardened hook where git never reads it while the OLD (ungated) hook stays
active, i.e. a false 'installed' that leaves the RCE open. (Note: the specific mangling
did NOT reproduce under this box's Git Bash — the path translated correctly both ways —
but the dependency is real and environment-specific, so it is removed rather than argued.)

Fix:
- Resolve the active hooks dir the way git itself does:
  'git rev-parse --path-format=absolute --git-path hooks' — honors core.hooksPath and
  returns an absolute FORWARD-SLASH path usable in every bash-on-Windows variant. We now
  write exactly where git reads. Fallback for git<2.31 normalizes via cygpath/tr.
- POST-INSTALL ASSERTION: after writing, confirm the gate block is present at git's
  resolved active hook path; if not, print ERROR and exit 1 instead of reporting success.
  A misplaced write can no longer masquerade as a successful, protective install.
- Refresh/chain/create paths unified through one success+assert tail; husky (sourced,
  no shebang) detected by path.

Verified: default, Windows-backslash core.hooksPath, and custom-relative dir all land
the gate at git's resolved path; re-run refreshes to a single block (idempotent); a
forced misplaced write triggers the ERROR/exit-1 assertion.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CsePmfHDMBKRNDLNb3TLD5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant