Research the signing and notarization strategy for macOS and Windows

[eimexdev]

Part of OpenBeat v0.1.0 public launch map.

Question

What signing and notarization strategy should OpenBeat use for trusted macOS and Windows GitHub Release artifacts, and how should its credentials be handled safely in GitHub Actions?

Research scope

macOS

• Required Apple certificate types for the bundled executable and .pkg.
• Signing order, hardened runtime, notarization, stapling, and verification.
• App Store Connect API keys or other CI authentication.
• Secret storage, rotation, and least-privilege practices.
• Verification using codesign, pkgutil, spctl, and current notarization tooling.

Assume the maintainer has an Apple Developer account and Developer ID distribution is available.

Windows

• Current Authenticode options for an open-source project: OV, EV, cloud signing, and reputable sponsorship programs.
• Cost, identity verification, key-storage requirements, timestamping, renewal, SmartScreen/reputation implications, and GitHub Actions support.
• Which executables should be signed and in what packaging order.
• Verification and credential-rotation procedures.

Research artifact

Use $research and primary vendor documentation. Link a repository Markdown summary from the resolution comment. The answer must be decision-ready: recommended providers/approaches, expected cost and setup time, CI architecture, credential model, and rejected alternatives.

Handoff

Implement macOS Developer ID signing and notarization in the release workflow and Implement Windows Authenticode signing in the release workflow are blocked on this decision.

[eimexdev]

Resolution

Use the documented inside-out signing and verification strategy in Signing and notarization strategy.

• macOS: use the maintainer’s existing Apple Developer Program membership; sign the bundled executable with Developer ID Application and hardened runtime, sign the final package with Developer ID Installer, notarize with notarytool, staple, and require codesign, pkgutil, stapler, and spctl verification before release.
• Windows: prefer the free SignPath Foundation open-source program; the application has been submitted and is pending review. If approval is unavailable for launch, use Azure Artifact Signing Public Trust Basic only during a release month, authenticate GitHub Actions with OIDC, timestamp and verify all inner PE files before packaging, then timestamp and verify the outer installer. Delete the Azure Artifact Signing account after the release rather than keeping it active year-round; Microsoft states that account deletion does not invalidate existing signatures. Do not revoke the certificate.
• Release gate: calculate checksums only after signing and stapling, then smoke-test the exact post-signing artifacts.

Research artifact committed on main in 5dbd95b.