[Bug]: macOS privileged helper is signed as com.nvidia.nvpair, so its pinned code-signing requirement always fails ("Privileged helper setup incomplete")

Start with the pinned requirement in desktop/native/Shared/HelperProtocol.swift (daemonCodeSigningRequirement) and the packaging config in desktop/electron-builder.config.ts. The signing script, internal-build/signing/macos/sign.ts, is not in the public repo, so a contributor needs maintainer access to change it. Done means codesign -dv on com.nvidia.nvpair.helper reports Identifier=com.nvidia.nvpair.helper, and nvpair-helper-ctl status returns reachable: true.

PAIR version or commit: 1.0.0 (CFBundleVersion 1.0.0.85), the official signed DMG

Affected component: Installer or update

Environment:

• macOS 26.6.2 (25G83), arm64 (Apple silicon), on two separate Macs
• Both Macs have NVIDIA PAIR 1.0.0 installed in /Applications, Developer ID signed, Team ID 6KR3T733EC.
• codesign --verify --deep --strict passes on the .app.
• The Application Firewall is off on both, so there is no functional impact today.

Steps to reproduce:

1. Install and launch NVIDIA PAIR 1.0.0 on macOS, and approve the background item.
2. Run codesign -dv /Applications/<PAIR>.app/Contents/MacOS/com.nvidia.nvpair.helper.
3. Run /Applications/<PAIR>.app/Contents/MacOS/nvpair-helper-ctl status.
4. Look at the mac-helper lines in the PAIR log (logs/nvpair.jsonl).

Expected behavior:

• The helper daemon is signed with Identifier=com.nvidia.nvpair.helper, as HelperConstants.daemonCodeSigningRequirement in desktop/native/Shared/HelperProtocol.swift requires.
• nvpair-helper-ctl status reports reachable: true with a daemonVersion.
• configure-firewall succeeds, and macHelperSetupComplete gets set.

Actual behavior:
codesign -dv on the helper daemon shows the app's identifier instead of the helper's:

Identifier=com.nvidia.nvpair
Authority=Developer ID Application: NVIDIA Corporation (6KR3T733EC)
TeamIdentifier=6KR3T733EC

The control tool itself is signed correctly (Identifier=nvpair-helper-ctl). nvpair-helper-ctl status returns:

{"ctlVersion":"1.0.0","reachable":false,"registration":"enabled"}

The two Macs fail in different ways:

• Mac A: the daemon (system/com.nvidia.nvpair.helper) is running, but every XPC connection is refused with Received message forbidden due to code signing requirement. PAIR logs Privileged helper setup incomplete: enabled Couldn't communicate with a helper application.

• Mac B: launchd never starts the daemon. launchctl print system/com.nvidia.nvpair.helper shows:

  • program identifier = Contents/MacOS/com.nvidia.nvpair (mode: 2), which does not exist in the bundle;
  • job state = spawn failed;
  • last exit code = 78: EX_CONFIG.

  nvpair-helper-ctl status waits 5 s for the daemon, and configure-firewall produces no output. PAIR logs ctl configure-firewall failed: Command failed: …/nvpair-helper-ctl configure-firewall and then Privileged helper setup incomplete: enabled no response from helper control tool.

Because macHelperSetupComplete is never set, this repeats at every launch. If the Application Firewall were on, the 7 networked binaries would get no allow rules.

The pinning works as designed and fails closed; only the identifier the daemon was signed with is wrong. It looks like the internal per-binary sign loop (internal-build/signing/macos/sign.ts, referenced in desktop/electron-builder.config.ts) signs com.nvidia.nvpair.helper with the app's identifier, for example without an explicit --identifier com.nvidia.nvpair.helper. We couldn't check this, because that script is not in the public repo.

Sanitized logs or screenshots:

{"level":"error","source":"mac-helper","sublevel":"ctl","message":"ctl configure-firewall failed: Command failed: /Applications/<PAIR>.app/Contents/MacOS/nvpair-helper-ctl configure-firewall\n"}
{"level":"error","source":"app","sublevel":"mac-helper","message":"Privileged helper setup incomplete: enabled no response from helper control tool"}
{"level":"error","source":"app","sublevel":"mac-helper","message":"Privileged helper setup incomplete: enabled Couldn’t communicate with a helper application."}

Confirmations:

• I searched existing issues for duplicates. (2026-10-16: none mention the helper or its signature.)
• This is not a security vulnerability. (The requirement check fails closed; the defect makes the helper unusable rather than bypassable.)
• I agree to follow the Code of Conduct.