fix: quote paths in exec command to handle workspaces with spaces

[aaronearles]

Fix: quote paths in exec command to handle workspaces with spaces

Summary

workspacePath (and executablePath) are interpolated into the shell command string without quoting in src/util.js line 65. When the workspace path contains spaces — common in OneDrive-synced environments like C:\Users\...\OneDrive - CompanyName\... — the path is truncated at the first space. Gitleaks silently scans the wrong directory, finds nothing, and the extension reports "No secrets found" with no indication anything went wrong.

Root Cause

// src/util.js line 65 — before
const command = `${executablePath} detect --log-level error --source ${workspacePath} --no-color --no-banner -v --no-git`;

Fix

// src/util.js line 65 — after
const command = `"${executablePath}" detect --log-level error --source "${workspacePath}" --no-color --no-banner -v --no-git`;

Both executablePath and workspacePath are quoted. The executable path is also quoted as it lives inside .vscode\extensions\ which may itself contain spaces on some systems.

---

Reproduction

Tested using gitleaks_8.19.2_windows_x64.exe from the installed extension on Windows.

Directory structure — identical .gitleaks.toml in all three dirs (proven by hash below), C:\temp\gitleaks\ is the decoy directory that only contains a clean file:

C:\TEMP
├───gitleaks
│       .gitleaks.toml
│       clean.tf
│
├───gitleaks test
│       .gitleaks.toml
│       secrets.auto.tfvars
│
└───gitleaks-test
        .gitleaks.toml
        secrets.auto.tfvars

Config files are identical — eliminating config as a variable:

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          0C04D83C492DB0C1257E53031AFB9776DE681E07BB89EB4615865B88E1683799       C:\temp\gitleaks\.gitleaks.toml
SHA256          0C04D83C492DB0C1257E53031AFB9776DE681E07BB89EB4615865B88E1683799       C:\temp\gitleaks test\.gitleaks.toml
SHA256          0C04D83C492DB0C1257E53031AFB9776DE681E07BB89EB4615865B88E1683799       C:\temp\gitleaks-test\.gitleaks.toml

Control — no spaces in path, works correctly:

.\gitleaks_8.19.2_windows_x64.exe detect --log-level error --source "C:\temp\gitleaks-test" --no-color --no-banner -v --no-git

Finding:     password    =   "Thisis@pa$$w0rd1234!@#$"
Secret:      Thisis@pa$$w0rd1234!@#$
RuleID:      generic-password-assignment
Entropy:     4.055958
File:        C:\temp\gitleaks-test\secrets.auto.tfvars
Line:        1
Fingerprint: C:\temp\gitleaks-test\secrets.auto.tfvars:generic-password-assignment:1

Bug — spaces in path, unquoted (current extension behavior). Path is truncated to C:\temp\gitleaks, the decoy directory is silently scanned, no findings, no error:

.\gitleaks_8.19.2_windows_x64.exe detect --log-level error --source C:\temp\gitleaks test --no-color --no-banner -v --no-git

(no output)

Fix — spaces in path, quoted. Correct directory scanned:

.\gitleaks_8.19.2_windows_x64.exe detect --log-level error --source "C:\temp\gitleaks test" --no-color --no-banner -v --no-git

Finding:     password    =   "Thisis@pa$$w0rd1234!@#$"
Secret:      Thisis@pa$$w0rd1234!@#$
RuleID:      generic-password-assignment
Entropy:     4.055958
File:        C:\temp\gitleaks test\secrets.auto.tfvars
Line:        1
Fingerprint: C:\temp\gitleaks test\secrets.auto.tfvars:generic-password-assignment:1

---

Why this matters

The failure mode is a silent false negative. When the truncated path happens to be a valid directory, gitleaks exits cleanly with no stderr output. The extension receives empty stdout and empty stderr and reports "No secrets found" — giving the user false confidence that no secrets are present.

A concrete real-world example: Windows creates two OneDrive directories side by side when a user has both personal and work/school accounts:

C:\Users\username\OneDrive                    ← personal (exists, typically empty)
C:\Users\username\OneDrive - CompanyName\     ← work/school sync root

If a workspace lives under OneDrive - CompanyName, the path is truncated at the first space and gitleaks silently scans the personal OneDrive\ directory instead — which is valid, empty, and returns no findings. The user sees "No secrets found" with no indication the wrong directory was scanned. This is a common environment for enterprise users, making this a likely failure mode in exactly the audience this extension targets.

---