security: Verify code signing and auto-update signature verification

[BernardJen]

The app ships an auto-updater pulling from GitHub releases. Confirm the update chain is trustworthy:

• macOS builds signed + notarized
• Windows builds signed
• Updater verifies signatures before applying updates

An unsigned auto-update channel is the most likely attack surface for a desktop app distributed this way.

[BernardJen]

Audit complete — findings verified, but signing cannot be implemented here

All three checkboxes fail today. Verified empirically against the shipped v2.7.0 artifact, not inferred from config:

$ codesign -dv --verbose=2 Input-Viewer-2.7.0-universal.dmg
Input-Viewer-2.7.0-universal.dmg: code object is not signed at all

$ spctl -a -t open --context context:primary-signature -v Input-Viewer-2.7.0-universal.dmg
source=no usable signature

Check	Status
macOS signed + notarized	❌ CSC_IDENTITY_AUTO_DISCOVERY: false in release.yml — built unsigned deliberately, no notarization step
Windows signed	❌ no signing configuration in build.win at all
Updater verifies signatures	❌ nothing is signed, so there is no signature to verify

On the updater specifically: electron-updater validates the SHA512 recorded in latest-mac.yml / latest.yml. That protects against corruption in transit, but the hash lives in the same feed as the artifact — so it does not protect against anyone able to publish a release. Trust in an update currently reduces to trust in the GitHub release and who has write access to this repo.

Why I did not fix it: signing requires an Apple Developer ID (plus notarization credentials) and a Windows code-signing certificate, added as repository secrets. The only secret configured is RELEASES_REPO_TOKEN. That is a procurement and key-custody decision, not a code change — it needs you.

What I did instead: recorded the posture in SECURITY.md under "Known posture" (PR #129), so users evaluating whether to deploy this see it rather than having to find this issue. #55's renderer hardening is in the same PR and is implemented.

Leaving this open — it's a real gap and the highest-value security work left. When you have certificates, the change is roughly: store them as secrets, drop CSC_IDENTITY_AUTO_DISCOVERY: false, add notarize to the mac config plus APPLE_ID/APPLE_APP_SPECIFIC_PASSWORD/APPLE_TEAM_ID, and add win.certificateSubjectName or a PFX. Happy to wire that up once the certificates exist.

[BernardJen]

On hold

Parking this at Bernard's request. Not because the finding is wrong — it stands, and it remains the most significant security gap in the project.

Recap of what was verified, against the shipped artifact rather than inferred from config:

$ codesign -dv --verbose=2 Input-Viewer-*-universal.dmg
code object is not signed at all

$ spctl -a -t open --context context:primary-signature -v ...
source=no usable signature

Check	Status
macOS signed + notarized	❌ CSC_IDENTITY_AUTO_DISCOVERY: false in release.yml
Windows signed	❌ no signing config in build.win
Updater verifies signatures	❌ nothing signed, so nothing to verify

electron-updater validates the SHA512 in latest-mac.yml / latest.yml, which covers corruption in transit but not a compromised release feed — the hash lives alongside the artifact. Trust currently reduces to who holds write access to this repo.

Why it is blocked rather than unfinished: signing needs an Apple Developer ID (plus notarization credentials) and a Windows code-signing certificate, added as repository secrets. The only secret configured is RELEASES_REPO_TOKEN. That is a procurement and key-custody decision, not a code change.

The posture is documented in SECURITY.md under "Known posture" so users evaluating the app see it rather than having to find this issue.

When certificates exist, the change is roughly one PR: store them as secrets, drop CSC_IDENTITY_AUTO_DISCOVERY: false, add notarize to the mac config plus APPLE_ID / APPLE_APP_SPECIFIC_PASSWORD / APPLE_TEAM_ID, and add win.certificateSubjectName or a PFX. Happy to wire it up then.