fix(secret-store): pass secrets via stdin instead of argv on macOS and Windows

[margaretjgu]

Closes #515.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	0.35s
✅ REPOSITORY	gitleaks	yes		no	no	36.13s
✅ REPOSITORY	git_diff	yes		no	no	0.03s
✅ REPOSITORY	secretlint	yes		no	no	1.54s
✅ REPOSITORY	trivy	yes		no	no	14.71s
✅ TYPESCRIPT	eslint	2		0	0	2.05s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by OX Security
Show us your support by starring ⭐ the repository

[github-actions]

The security fix is correct and the tests properly verify the new behavior. A few issues worth flagging:

Bug: Windows stdin reading is fragile

`$secure = ConvertTo-SecureString -String ([Console]::In.ReadToEnd().TrimEnd(@([char]"\`n", [char]"\`r"))) -AsPlainText -Force; `

TrimEnd only strips trailing newlines/CRs, but execSync with input option may or may not append a newline depending on the Node version and OS. More importantly, if the secret itself ends with \n or \r (unusual but valid), this silently truncates it. A more robust approach would be to strip only the final line terminator that the shell/pipe adds, or better, use -replace '[\r\n]+$','' in PowerShell, which has the same edge-case risk but is at least more idiomatic.

More critically: does [Console]::In.ReadToEnd() work correctly when PowerShell is invoked with -EncodedCommand? The stdin pipe should still be inherited, but this is worth verifying — if PowerShell consumes stdin for something else in encoded-command mode, the read would block or return empty.

Potential issue: execOpts signature change

The diff shows execOpts(5_000, secret) and execOpts(10_000, secret) but the original execOpts function signature isn't shown. If execOpts didn't previously accept a second argument, this either silently ignores the input or there's a separate (not shown) change to execOpts that adds input support. If the latter, the review is incomplete without seeing that change — the secret-passing mechanism lives there and should be audited.

Minor: Windows single-quote escaping removed without replacement

The old code did secret.replace(/'/g, "''") before embedding in the PowerShell string. The new code removes this (correctly, since the secret is no longer embedded). But the target and user variables still use the same replace(/'/g, "''") pattern and are still interpolated directly into the PowerShell expression — that's fine and unchanged, just noting it's consistent.

The core approach (stdin instead of argv) is correct for both platforms.

[margaretjgu]

TrimEnd fixed in latest commit. execOpts sets input on the opts object, same pattern as the existing Linux secret-tool path.