[GH-ISSUE #4125] [Bug] Windows package verifiers cannot spawn npm command scripts #1622

New issue

Closed

opened 2026-10-16 21:08:06 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:08:06 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4125

The real ordinary-user Windows lane for scripts/verify-packaged-wasm-artifact.mjs cannot reach package verification because both its pack helper and install step call child_process.execFile("npm", ...). The standard Windows Node distribution exposes npm.cmd, and execFile does not execute command scripts, so the verifier exits with spawn npm ENOENT.

Reproduced from PR #4117 head ecd04eea840385caeb7b595c827845b6ff8c6c88 on Windows 11 x64 with Node 24.18.0 and npm 11.16.0. The lane ran as an ordinary desktop user at BelowNormal priority with two logical CPUs and a 2 GiB Job limit. It failed in 21.31 seconds with 319,549,440-byte peak Job commit, produced 832 bytes of stderr, and settled at Job active-process count zero.

The environment had the standard portable Node directory first on PATH (node.exe, npm.cmd) and also supplied npm_execpath. scripts/verify-windows-package.mjs and scripts/verify-packaged-ghidra-windows.mjs already avoid this failure by executing process.execPath plus the npm CLI path, but the generic package helpers duplicate a raw npm interpretation.

Expected behavior: package verifiers should resolve the active npm CLI once at the owning process boundary and invoke it through Node on every platform. They should preserve the caller-selected npm implementation, arguments, environment, timeout, output limits, and error details. Please inspect all consumers of scripts/lib/verify-package-core.mjs so the fix removes duplicated npm launching rather than adding another WASM-only workaround.

The complete local receipt and stderr are retained under /tmp/rea-windows-e2e-20261013/results/issue4109-fix/; no package, binary, or credentials are published.

Originally created by @N0zoM1z0 on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4125 The real ordinary-user Windows lane for `scripts/verify-packaged-wasm-artifact.mjs` cannot reach package verification because both its pack helper and install step call `child_process.execFile("npm", ...)`. The standard Windows Node distribution exposes `npm.cmd`, and `execFile` does not execute command scripts, so the verifier exits with `spawn npm ENOENT`. Reproduced from PR #4117 head `ecd04eea840385caeb7b595c827845b6ff8c6c88` on Windows 11 x64 with Node 24.18.0 and npm 11.16.0. The lane ran as an ordinary desktop user at BelowNormal priority with two logical CPUs and a 2 GiB Job limit. It failed in 21.31 seconds with 319,549,440-byte peak Job commit, produced 832 bytes of stderr, and settled at Job active-process count zero. The environment had the standard portable Node directory first on `PATH` (`node.exe`, `npm.cmd`) and also supplied `npm_execpath`. `scripts/verify-windows-package.mjs` and `scripts/verify-packaged-ghidra-windows.mjs` already avoid this failure by executing `process.execPath` plus the npm CLI path, but the generic package helpers duplicate a raw `npm` interpretation. Expected behavior: package verifiers should resolve the active npm CLI once at the owning process boundary and invoke it through Node on every platform. They should preserve the caller-selected npm implementation, arguments, environment, timeout, output limits, and error details. Please inspect all consumers of `scripts/lib/verify-package-core.mjs` so the fix removes duplicated npm launching rather than adding another WASM-only workaround. The complete local receipt and stderr are retained under `/tmp/rea-windows-e2e-20261013/results/issue4109-fix/`; no package, binary, or credentials are published.

bsakaguchi closed this issue

2026-10-16 21:08:07 +00:00

bsakaguchi commented

2026-10-16 21:08:07 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 15, 2026):

Fix proposed in #4153.

The structural fix gives npm invocation one owner in scripts/lib/verify-package-core.mjs, preserves caller-selected npm_execpath, uses the Node-adjacent npm CLI on Windows when it is absent, and removes the two duplicated Windows implementations. All seven package-verifier consumers now share that boundary.

Real ordinary-user Windows 11 verification passed both paths with Node 24.18.0/npm 11.16.0: caller-selected npm and the no-npm_execpath fallback each completed --version plus a real pack of a file whose name contains spaces. The resulting 227-byte tarballs were byte-identical, source files were preserved, stderr was empty, output was 740 bytes, and Job0. The 1 GiB/two-CPU/BelowNormal lane used 58.431 s Job wall, 8.531 sampled CPU seconds, 128,131,072-byte peak Job commit, and 183,529,472-byte sampled family working set.

check:fast, the new process-boundary regression, existing pack-isolation coverage, and the release-artifact canary pass. Full packaged-WASM completion is still not claimed because independent #4128, #4134, and #4136 remain; no bypass for them is included.

@N0zoM1z0 commented on GitHub (Oct 15, 2026): Fix proposed in #4153. The structural fix gives npm invocation one owner in `scripts/lib/verify-package-core.mjs`, preserves caller-selected `npm_execpath`, uses the Node-adjacent npm CLI on Windows when it is absent, and removes the two duplicated Windows implementations. All seven package-verifier consumers now share that boundary. Real ordinary-user Windows 11 verification passed both paths with Node 24.18.0/npm 11.16.0: caller-selected npm and the no-`npm_execpath` fallback each completed `--version` plus a real pack of a file whose name contains spaces. The resulting 227-byte tarballs were byte-identical, source files were preserved, stderr was empty, output was 740 bytes, and Job0. The 1 GiB/two-CPU/BelowNormal lane used 58.431 s Job wall, 8.531 sampled CPU seconds, 128,131,072-byte peak Job commit, and 183,529,472-byte sampled family working set. `check:fast`, the new process-boundary regression, existing pack-isolation coverage, and the release-artifact canary pass. Full packaged-WASM completion is still not claimed because independent #4128, #4134, and #4136 remain; no bypass for them is included.

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-31 00:54:13 +00:00

[PR #1622] [MERGED] perf(evm): avoid repeated cleanup diagnostics #4706

bsakaguchi referenced this issue

2026-10-31 00:54:24 +00:00

[PR #1648] [MERGED] fix(ci): check decoded reference paths and restore formatting #4725