gitleaks scans one commit too few on Windows: shell:true corrupts the --log-opts argument

[ppcvote]

Description

gitleaks.ts spawns with { cwd, shell: true } and builds the range argument with POSIX single quotes:

// src/proxy/processors/push-action/gitleaks.ts:37
const child = spawn(command, args, { cwd, shell: true });

// src/proxy/processors/push-action/gitleaks.ts:174
`--log-opts='--first-parent ${rootCommit === commitFrom ? rootCommit : `${commitFrom}^`}..${commitTo}'`,

With shell: true, Node joins the command and its arguments into a single command line and hands it to the platform shell. cmd.exe does not treat ' as a quote character, and does treat ^ as an escape character. Both facts bite here.

Measured on Windows by spawning an argv echoer through the same code path, with commitFrom = abc123 and commitTo = def456:

intended, one argv entry:
  ["--log-opts='--first-parent abc123^..def456'"]

actual, shell: true:
  ["--log-opts='--first-parent", "abc123..def456'"]

actual, no shell:
  ["--log-opts='--first-parent abc123^..def456'"]

Two things go wrong at once. The argument is split in two at the space, because the quotes are not quotes to cmd.exe. And the ^ is silently deleted.

Why the ^ matters

<sha>^..<sha> and <sha>..<sha> are different revision ranges. The first starts at the parent of commitFrom, the second starts at commitFrom itself. Losing the caret narrows the range by one commit, and the commit that drops out is the first commit of the push being scanned.

So on Windows this is not a crash or a visible error. gitleaks runs, exits 0, and reports no leaks, having quietly skipped a commit that was in scope. For a secret-scanning proxy that is a silent gap rather than a cosmetic bug.

Expected behavior

The range argument reaches gitleaks as a single argv entry, identical on every platform, and covers the full range including the parent commit.

Environment

Windows 10, Node 22.22.0, git-proxy at 2696ca49. Not reproducible on Linux or macOS: /bin/sh strips the quotes and leaves ^ alone, which is why CI has not caught it. The repository does run a Windows job, but nothing currently asserts on the arguments passed to spawn.

Notes

Removing shell: true fixes both symptoms, and the quotes then become unnecessary since the argument is passed as one array element. runCommand is only ever called with git and gitleaks, both native executables, and I verified spawn('git', ...) without a shell resolves correctly through PATH on Windows, so nothing depends on shell resolution here.

I have a fix and a regression test ready, and would be happy to open a PR against this issue.