Security: workspace-changes runs repository-local Git hooks

[aliceQWAS]

In the latest DSH Web and Desktop versions, workspace-changes runs git add automatically when a turn starts. If the opened project’s .git/config sets core.hooksPath, Git can run a post-index-change hook with the DSH user’s privileges, without a requested tool call.
Here is a harmless macOS/Linux reproduction. The hook only writes a marker:
demo_dir="$(mktemp -d)"
git init -q "$demo_dir/repo"
mkdir -p "$demo_dir/repo/.hooks"
printf 'demo\n' > "$demo_dir/repo/README.md"

cat > "$demo_dir/repo/.hooks/post-index-change" <<'EOF'
#!/bin/sh
printf 'hook ran\n' > ../dsh-poc-marker.txt
EOF

chmod +x "$demo_dir/repo/.hooks/post-index-change"
git -C "$demo_dir/repo" config --local core.hooksPath .hooks
printf 'Open in DSH: %s\n' "$demo_dir/repo"
Open the printed directory in DSH Web or Desktop and start a turn with “hello.” Then run cat "$demo_dir/dsh-poc-marker.txt" in the original shell. It prints hook ran.
Could the automatic snapshot disable repository-local hooks? This matters for copied or extracted projects that preserve their .git directory.

[argszero]

Reproduced on git 2.50.1 (Apple Git-155) with your exact relative form core.hooksPath .hooks.

What fires. With .git/config carrying core.hooksPath=.hooks and the work tree holding .hooks/post-index-change mode 0755, git add --all --ignore-errors runs that hook — deterministically, 3/3, and GIT_TRACE=1 names it (run-command.c:673 run_command: .hooks/post-index-change 0 0). The private-index shape workspace-changes uses for its turn-start snapshot (GIT_INDEX_FILE=<scratch>/index plus GIT_OBJECT_DIRECTORY) fires it too, and so does git write-tree. rev-parse, ls-files --stage and check-ignore do not.

The environment scrub does not cover it. GitRunner.run() in packages/deliverables/workspace-changes/src/git.ts sets GIT_CONFIG_COUNT=0 GIT_TERMINAL_PROMPT=0 GIT_OPTIONAL_LOCKS=0 LC_ALL=C, and the comment there says the credential scrub removes ambient GIT_CONFIG_KEY_n entries. That part is true — SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i in packages/subprocess/subprocess/src/index.ts drops those names — but it only cancels environment-injected config. .git/config is read either way:

invocation (GitRunner's environment, verbatim)	repository hook runs
git add --all	yes
git -c core.hooksPath=/dev/null add --all	no
git -c core.hooksPath= add --all (empty value)	no
git -c core.hooksPath=<nonexistent absolute path> add --all	no

So the answer to your question is yes — and the repository already carries the form. packages/experimental/worktree/src/index.ts:132 prefixes every git call with -c core.hooksPath=/dev/null -c core.fsmonitor=false, and scripts/change-scope.ts:62 does the same for core.fsmonitor. The product path (GitRunner.run()) is the one place those flags are missing. Same channel, second caller: packages/boot/plugin-manager/src/github-connection.ts:44 runs execa('git', ['-c', 'credential.helper=', 'ls-remote', '--', repository, 'HEAD']) while resolving an install spec, inherits the workspace configuration the same way, and does not route through ctx.subprocess, so it needs its own fix.

One scope note: hardening belongs on git invocations the harness starts for its own bookkeeping (working-tree snapshots, tree diffs, ignore checks, install probing). A git commit the user asks for through the shell tool should keep the hooks they installed on purpose — the distinguishing fact is argv[0], not the working directory.

Related: #9217 covers the fsmonitor half of the same boundary (core.fsmonitor in .git/config: bare git add runs it twice, -c core.fsmonitor=false zero). app-boot's BOOTSTRAP_NAMES already refuses GIT_CONFIG_*, GIT_SSH* and GIT_EXTERNAL_DIFF arriving with a clone; .git/config is the channel that is left.

[argszero]

A mitigation for the half a plugin can reach is now published, so the gap can be
closed in a deployment today without waiting for the in-tree change.

@argszero/dsh-git-hook-guard@0.1.0 — npm · source

dsh plugin --profile <name> add @argszero/dsh-git-hook-guard

Mount it, or apply the bundled patch:

- insert:
    - id: git-hook-guard
      name: '@argszero/dsh-git-hook-guard'
      inject:
        - subprocess

It shadows spawn on the live subprocess service instance and, for the git
invocations the harness itself starts, inserts the two flags this repository
already uses for its own git calls
(packages/experimental/worktree/src/index.ts:132):

-c core.hooksPath=/dev/null -c core.fsmonitor=false

Three things about the shape, since they are what decides whether it is worth
anything here:

• The scope is the credential-scrub marker, not "any git call". An invocation
  is selected only when argv[0] is a git executable and its explicit
  environment carries GIT_CONFIG_COUNT=0 — the marker GitRunner.run() writes
  into every git child it starts. A git command the user asks for goes through the
  shell tool, whose argv[0] is the shell, so it fails the executable test long
  before the environment is consulted. The hooks a user installed on purpose keep
  running; git commit still runs its pre-commit hook. (scope: all widens it
  for operators who want that, and the report says which scope is in force.)
• It declines rather than overrides. A caller that already sets
  core.hooksPath or core.fsmonitor is respected and left alone — that is the
  worktree call site above — because git resolves a repeated -c for one key in
  favour of the later one, so an inserted copy could be silently outvoted anyway.
• It fails open. A throw inside the decision is caught, counted as failures,
  and followed by the caller's own spec: a guard whose own bug broke every child
  process the harness starts would be a worse defect than the missing -c.

report mode is there for anyone who wants the number before trusting a rewrite
with it: it runs the same decision, counts wouldHarden, and writes nothing.

What it does not cover, and the plugin prints this list on every snapshot
rather than only in its README:

• A git command that does not go through the subprocess service is invisible to
  it. packages/boot/plugin-manager/src/github-connection.ts probes install specs
  with its own execa() call (git ls-remote), and repository scripts spawn git
  directly. That path is outside the seam a plugin can reach — I am not
  claiming coverage of it here, only naming it.
• Only invocations that start after the mount are inspected.
• spawnTerminal is deliberately not shadowed: a persistent shell is the user's
  own.
• It is an argument-level mitigation, not a sandbox — anything outside the harness
  (the user's shell, another tool, a scheduled job) still runs repository hooks.

The real fix is still the in-tree one, and it is one line of shape: GitRunner.run()
in packages/deliverables/workspace-changes/src/git.ts builds its argv without the
flags while packages/experimental/worktree/src/index.ts:132 already carries both.
Until that lands, this is the seam a plugin can reach — and when it lands, the
plugin becomes redundant rather than harmful, which is the property I would want
from a mitigation.

For anyone re-measuring: the discriminator that the existing environment scrub is
not the fix is that GIT_CONFIG_COUNT=0 GIT_TERMINAL_PROMPT=0 GIT_OPTIONAL_LOCKS=0 LC_ALL=C git add --all --ignore-errors still fires the hook (measured on git
2.50.1, Apple Git-155) — the scrub cancels environment-injected configuration,
which is what its comment claims, and says nothing about the configuration git
reads from the invocation's own working directory. git write-tree and the
private-index shape snapshotTree uses (GIT_INDEX_FILE + GIT_OBJECT_DIRECTORY)
fire it too; rev-parse, ls-files --stage and check-ignore do not.