Powershell Get-AuthenticodeSignature fails

[Lemonexe]

Hello, we are using electron-updater in Trezor Suite project, and ever since the update from 6.7.3 → 6.8.3, we are getting errors in Sentry:

Error: Command failed: set "PSModulePath=" & chcp 65001 >NUL & powershell.exe -NoProfile -NonInteractive -InputFormat None -Command "Get-AuthenticodeSignature -LiteralPath 'C:\Users\[*]\AppData\Local\@trezorsuite-desktop-updater\pending\temp-Trezor-Suite-26.4.2-win-x64.exe' | ConvertTo-Json -Compress"

The path seems correct, it's the same that electron-updater used in the past.
Any thoughts what change could have caused the regression, or how to debug it, how to reproduce it? 🤔
Thank you very much for any advice or solution 🙏

Related issues

Seems related – same failed command: #2589, #7127, #8162, #8822
We redact user data in Sentry events, so it is unknown if special characters in user name cause this, as was the case previously.

Context

All error events we have are at Electron 40.1.0, node 24.11.1.
Windows builds: 67% Windows 10.0.19045, 22 % Windows 10.0.26200 (the stable releases), 11 % various other builds

[mmaietta]

This is particularly confusing, as there's no relevant code changed between those versions
https://github.com/electron-userland/electron-builder/compare/electron-updater@6.7.3...electron-updater@6.8.3
No changes in builder-util-runtime. Only changes within electron-updater are in the files listed below:

packages/electron-updater/CHANGELOG.md
packages/electron-updater/package.json
packages/electron-updater/src/differentialDownloader/DataSplitter.ts
packages/electron-updater/src/differentialDownloader/DifferentialDownloader.ts
packages/electron-updater/src/differentialDownloader/multipleRangeDownloader.ts
packages/electron-updater/src/main.ts
packages/electron-updater/src/providers/GitHubProvider.ts

DO NOTE as the ultimate workaround:
It is possible to completely remove the powershell Windows signature verification approach with a native windows implementation instead
https://www.electron.build/win.html#how-do-use-a-custom-verify-function-to-enable-nsis-signature-verification-alternatives-instead-of-powershell

[mmaietta]

Split this into a separate comment since it's all AI generated. Did some research via Claude and the following came back:

What the code does today

packages/electron-updater/src/windowsExecutableCodeSignatureVerifier.ts builds the command this way:

const executable = `set "PSModulePath=" & chcp 65001 >NUL & powershell.exe`
const args = ["-NoProfile", "-NonInteractive", "-InputFormat", "None", "-Command", command]
const options: ExecFileOptions = { shell: true, timeout }
…
const tempUpdateFile = unescapedTempUpdateFile.replace(/'/g, "''")  // only single-quote escape
execFile(...preparePowerShellExec(
  `"Get-AuthenticodeSignature -LiteralPath '${tempUpdateFile}' | ConvertTo-Json -Compress"`,
  20 * 1000), …)

Two important properties of that:

1. shell: true means Node concatenates executable + " " + args.join(" ") and runs it through cmd.exe /d /s /c "…". So everything traverses cmd.exe first, then PowerShell.
2. The only sanitization on the file path is doubling single quotes. Nothing is done about cmd-level metacharacters or non-ASCII bytes.

Why it's failing — the likely causes

The class of bug is "the path that lands inside the single-quoted PowerShell argument contains something that doesn't survive the cmd.exe → powershell.exe handoff." Concretely, on the affected machines one or more of these is true:

• Username/profile path contains a cmd metacharacter (& ^ | < > ( ) % or a stray ! under delayed expansion). Inside cmd, even if PowerShell would treat the character as literal, cmd parses the whole line first and a & in a username will split the command. The current escaping in the verifier doesn't address cmd-level chars at all — it only deals with PowerShell's '.
• Non-ASCII characters in the user folder name. chcp 65001 raises the console code page, but Node passes argv to cmd.exe as ANSI on some Windows builds, so multibyte chars (umlauts, cyrillic, accents — the same family that triggered Certificates with special characters are not accepted anymore since electron-updater v1.6.9 #8162) can be mojibake'd before PowerShell ever sees them. The reporter explicitly flags this as the previous root cause and can't rule it out now because of redaction.
• Node 24 Windows arg-quoting changes. All Sentry events come from Electron 40.1.0 / Node 24.11.1. Node 22/24 tightened how child_process quotes args on Windows (CVE‑2024‑27980 follow-ups). With shell: true, the resulting cmd.exe /d /s /c "…" line is more sensitive to embedded " and ^ than it used to be. The set "PSModulePath=" is itself a quoted token that can collide with the outer wrapping cmd applies, intermittently breaking the whole pipeline.
• Machine-level PowerShell policy / profile. Even with -NoProfile and PSModulePath cleared, group-policy execution policy or AppLocker rules can refuse to run signed-policy scripts. Those failures bubble up as a generic "Command failed" with a stderr they're losing.

There is nothing in the 6.7.3 → 6.8.3 diff that changed this verifier directly (6.8.0 added differential-download progress events; 6.8.1 was lint cleanup; 6.8.2 fixed non-semver tag parsing; 6.8.3 was Kilian's "Remove console logs for autoupdate checks" #9561). So the regression is best explained by 6.8.3 removing the console.log lines that were previously swallowing or de-prioritising the rejection in their telemetry pipeline — Sentry now sees an error that was always there, or the auto-updater now rejects to a path Sentry captures. Either way, the underlying PowerShell call has been brittle for years and they just gained visibility.

What to fix

In rough order of bang-for-buck:

1. Stop going through cmd.exe. Drop shell: true and call powershell.exe directly. That removes one whole layer of quoting and the & chcp 65001 >NUL & chaining problem. Set PSModulePath via the env option of execFile, not via an inline set command.

2. Switch from -Command to -EncodedCommand. Build the PowerShell script as a UTF‑16LE string, base64-encode it, and pass it as a single argv token. Encoded commands bypass all shell quoting/escaping issues — the path-with-quote, the non-ASCII path, the &-in-username, and the umlaut-in-cert classes of bug all go away because PowerShell decodes the argument internally.

3. Pass the file path to PowerShell as a parameter, not by string-templating it into the script body. Two ways to do this safely:

   • Use -File with a small embedded .ps1 and pass the path as a -LiteralPath argv argument so PowerShell does the parsing.
   • Or invoke a script block that reads $args[0] and pass the path as a separate argv element. Either way, no in-band quoting.

4. Harden the escape function for the interim release. If keeping the current architecture short-term, the replace(/'/g, "''") is insufficient. At minimum: reject paths containing \0, double any backticks, and verify the path round-trips through path.normalize. But this is a band-aid — the proper fix is (1)+(2)+(3).

5. Capture stderr in Sentry-friendly form. In handleError, currently a reject(error) loses stderr. Wrap it: reject(new Error(${error.message}; stderr: ${stderr})). This is what would let the reporter actually pinpoint whether it's the username, encoding, or policy. Worth doing as a separate small PR so the next report has actionable data.

6. Longer term, consider replacing PowerShell entirely with a native WinTrust API call (via node-gyp/koffi to WinVerifyTrust) or shelling out to signtool verify /pa /v. PowerShell-based verification has been the source of issues AutoUpdate takes 60 seconds to fail validating signature on Windows 7 due to PowerShell version #2421, [NSIS] Long time between 100% download progress and update-downloaded event #2535, powershell Get-AuthenticodeSignature fails intermittently #2589, Auto update failed while executing the powershell command #7127, Certificates with special characters are not accepted anymore since electron-updater v1.6.9 #8162, Broken user name parsing on Windows leading to failed installs/updates #8822, and now Powershell Get-AuthenticodeSignature fails #9688. The repeated pattern is signal that the abstraction is wrong.

Suggested concrete patch shape

function preparePowerShellExec(scriptUtf16LE: Buffer) {
  const args = [
    "-NoProfile", "-NonInteractive", "-InputFormat", "None",
    "-EncodedCommand", scriptUtf16LE.toString("base64"),
  ]
  const options: ExecFileOptions = {
    timeout: 20_000,
    env: { ...process.env, PSModulePath: "" }, // no inline `set`
    windowsHide: true,
    // no shell:true — call powershell.exe directly
  }
  return ["powershell.exe", args, options] as const
}

export function verifySignature(publisherNames: string[], filePath: string, logger: Logger) {
  const ps = `Get-AuthenticodeSignature -LiteralPath $args[0] | ConvertTo-Json -Compress`
  const encoded = Buffer.from(ps, "utf16le")
  return new Promise<string | null>((resolve, reject) => {
    execFile(...preparePowerShellExec(encoded), { ... }, (error, stdout, stderr) => {
      // …existing parseOut / publisher matching, but now reject with combined error+stderr
    })
    // pass filePath as argv[0] of the script via `-File`/`-Command` block as appropriate
  })
}

The two non-negotiable changes are: no shell: true and -EncodedCommand.

---

Dev Note:
In terms of long-term, I don't think we're able to remove powershell from this as we can't guarantee a tool (like for signtool verify /pa /v) will be present on the user's system.

[mmaietta]

Picking up this issue and working on it in #9764