← Commit history

harden: build Windows browser candidates only on win32 (cwd-relative path class)

Kyle Bergstedt ·d3d7c39bd2 · ·parent 06e4aed
On mac, path.join('C:\Program Files', ...) is NOT absolute, so candidates were probed at <cwd>/C:\Program Files/... - a wrong-but-real answer was possible. Gating construction removes the class; zero behaviour change. Unreleased; rides next version.
2 files changed +27−2
CHANGELOG.md+15
@@ -2,6 +2,21 @@  ## UNRELEASED (rides the next version) — AD-base re-discovery + self-guarded powershell primitives +### Windows browser candidates are no longer built on macOS (cwd-relative path class)++`listSystemBrowsers()` built its Windows candidate paths on every platform and relied on+`fileExists()` to drop them. That was safe — but safe by the *consumer's* behaviour rather than+by the value's, and the values themselves were the trap the fleet audit named: on macOS,+`path.join('C:\\Program Files', 'Google', ...)` yields `C:\Program Files/Google/...`, which is+**not absolute**, so it was probed at `<cwd>/C:\Program Files/...` — a path that could in+principle exist and become a wrong-but-real answer. Same class as an `|| ''` default resolving+against cwd.++Windows candidates are now constructed only when `process.platform === 'win32'`. A Windows path+can never match on mac, so this is zero behaviour change (verified: same single Chrome candidate+resolved, no non-absolute candidates) while removing the class outright and dropping five+pointless syscalls per call. Windows behaviour is byte-identical.+ ### Stale AD base after an AD self-update (real bug, found by the fleet's fallback-chain rule)  pup cached its resolved direct-API base permanently (`_adApiBase` / `_adVerifiedBase`, both
src/chrome.js+12−2
@@ -113,16 +113,26 @@ function detectChrome() { // Testing download. listSystemBrowsers probes the standard install locations and // returns EVERY drivable system browser it finds, in preference order (Chrome, then Edge). function listSystemBrowsers() {+  // v1.9.86: the Windows candidates are built ONLY on win32. They were previously built+  // on every platform and relied on fileExists() to drop them — safe, but safe by the+  // CONSUMER's behaviour rather than by the value's, and the values themselves were a+  // trap: on macOS `path.join('C:\\Program Files', 'Google', ...)` yields+  // "C:\Program Files/Google/..." which is NOT ABSOLUTE, so it was probed at+  // <cwd>/C:\Program Files/... — a path that could in principle exist and become a+  // wrong-but-real answer. Same class as an `|| ''` default resolving against cwd.+  // Gating construction removes the class outright (a Windows path can never match on+  // mac anyway) and drops 5 pointless syscalls per call. Windows behaviour is unchanged.+  const IS_WIN = process.platform === 'win32';   const pf   = process.env['PROGRAMFILES']      || 'C:\\Program Files';   const pf86 = process.env['PROGRAMFILES(X86)'] || 'C:\\Program Files (x86)';   const lad  = process.env['LOCALAPPDATA']      || '';   const j = (base, ...rest) => (base ? path.join(base, ...rest) : null);-  const chromePaths = [+  const chromePaths = !IS_WIN ? [] : [     j(pf,   'Google', 'Chrome', 'Application', 'chrome.exe'),     j(pf86, 'Google', 'Chrome', 'Application', 'chrome.exe'),     j(lad,  'Google', 'Chrome', 'Application', 'chrome.exe'),   ].filter(Boolean);-  const edgePaths = [+  const edgePaths = !IS_WIN ? [] : [     j(pf86, 'Microsoft', 'Edge', 'Application', 'msedge.exe'),     j(pf,   'Microsoft', 'Edge', 'Application', 'msedge.exe'),   ].filter(Boolean);