Desktop release signing checklist: Windows, macOS and Linux

Before you publish a desktop release, confirm that every executable is signed, signatures are timestamped, the macOS build is notarized, checksums are published, and signing is restricted to your pipeline. Then download the release the way a user would and verify it. A checklist you run every time beats a heroic fix after a bad release.

Before the build

1. The build runs from a protected branch or tag, with required review.
2. Tools and dependencies are pinned, so a rebuild matches. See reproducible builds.
3. The signing identity is current. Check expiry dates, since new certificates are capped at 460 days. See renewal planning.

Signing

1. Sign the installer and every executable and library inside it. Microsoft notes that unsigned files start from zero reputation with each release.
2. Do not modify any file after signing, which can break the signature.
3. Timestamp each Windows signature, using SHA-256 for the file and the timestamp digest. Why timestamps matter.
4. On macOS, sign with your developer identity and submit for notarization, then confirm the build opens cleanly after download. See what Gatekeeper checks.
5. On Linux, sign repository metadata or release artifacts, and publish the key fingerprint. For apt users, see signed-by setup.

Key access

1. Keys live in hardware or a managed signing service, not on a build agent disk.
2. Only the release pipeline can request signatures, and every request is logged.
3. A named owner and backup exist for each key.
4. A key compromise plan exists and has been read by more than one person.

Publishing

1. Publish SHA-256 hashes in at least two places.
2. Put short verification steps next to the download button.
3. Ship an SBOM with the release. See what to put in an app SBOM.
4. Keep a record of what you signed and when.

After publishing

Download the artifact from the public URL on a clean machine of each OS. Verify the signature and compare hashes. Open the installer and confirm the publisher name appears as expected.

Keep a release record

For every release, store the commit, build number, artifact hashes, signing identity, timestamp authority used and the name of the person who approved it. A short record in the repository or release ticket is enough. When something goes wrong later, this record is the difference between knowing in minutes which files are yours and guessing. It also helps with customer questions and audits.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how a failing check blocks a merge, which is the same idea as blocking a release when signing checks fail.

Quick check

Last reviewed: 19 October 2026.