Why a checksum alone is not enough

A SHA-256 proves a file arrived intact. It does not prove who made it: whoever could replace an installer could replace the checksum list in the same action, and both would still match. So we sign the checksum list itself, and publish the key here rather than next to it.

What the signature covers

One signature over SHA256SUMS covers every artifact that file lists: the installers for every platform, and the CLI binaries. Two things published with a release are deliberately outside it and you should know which: the CycloneDX SBOM, and the updater bundles. Verify those against the release page rather than against this manifest.

Why the key is on this page

The signature and checksums are on GitHub. The key is here. Forging a download means compromising both, not one.

If verification fails

Do not install it. Tell us at [email protected] and we will confirm what the current release should be.

An opinion that is not ours

Every release also carries VIRUSTOTAL.md, listing a report link for each installer keyed to that file's own SHA-256, so any independent scan of the exact bytes you downloaded is one click away across roughly seventy engines. We publish the lookup rather than a verdict of our own: the point is that you do not have to take ours.

Who signed it, not just that it is intact

The minisign check above proves the manifest came from whoever holds our release key. It cannot tell you who that was. The Sigstore signature can, and it leaves a public record.

Recent releases also carry SHA256SUMS.sigstore.json, a single bundle produced by keyless Sigstore signing that holds the signature, the certificate and the transparency log entry together. The certificate binds the signature to a verified identity, and the entry is recorded in Sigstore's public, append-only transparency log. So the fact that this manifest was signed, by whom, and at what time, is something you can look up rather than something we tell you. Coverage is not yet every release: the bundle is present from v0.1.156 with the exception of v0.1.158, and is produced unconditionally from v0.1.160 onward. The minisign signature below is the one that covers more releases and needs nobody.

cosign verify-blob SHA256SUMS \
  --bundle SHA256SUMS.sigstore.json \
  --certificate-identity [email protected] \
  --certificate-oidc-issuer https://github.com/login/oauth

That identity is [email protected], via GitHub, and it is what the current release's certificate carries. Be precise about what that means: the command above pins the identity you are willing to accept, which is the right way to use it. Our signing tool does not itself pin one, so if a certificate ever names a different identity or issuer, the command fails and you should stop and tell us rather than relaxing the flags. Two independent signatures over the same manifest is deliberate: minisign depends on nobody and works offline, Sigstore proves the signer. Neither one replaces the other.

The Sparcle release signing key

Ed25519, via minisign (brew install minisign, apt install minisign). This key signs the checksum manifest of every Bolt release.

RWR074VTKBGzGWsQbnByhGrH9pQG5uHOJSgqL8rs5Zu4GQAxZ1C+JIza

If this key ever changes we will say so here and explain why. A key that changes without explanation is a reason to stop and ask us.

Verifying, step by step

These commands work on the current release. Signing coverage is not uniform across our history and we would rather you knew where it stops: every release from v0.1.155 onward carries a signed manifest, and before that most but not all do, so on an older tag step 2 may have nothing to verify against.

1. Download the checksums and the signature

Both live on the release you downloaded from. SHA256SUMS lists a SHA-256 for every installer and CLI binary in that release; SHA256SUMS.minisig is our signature over that file.

curl -LO https://sparcle.app/releases/latest/SHA256SUMS
curl -LO https://sparcle.app/releases/latest/SHA256SUMS.minisig

2. Check the signature against our key

This is the step that proves origin. If it fails, stop. The checksums themselves cannot be trusted, so verifying against them would be meaningless.

minisign -Vm SHA256SUMS -P 'RWR074VTKBGzGWsQbnByhGrH9pQG5uHOJSgqL8rs5Zu4GQAxZ1C+JIza'

3. Check your download against the checksums

Only once the signature verifies. Substitute the name of the file you actually downloaded: the manifest names the version you fetched, so a filename copied from this page will match nothing. On macOS and Linux it prints the filename followed by OK.

grep ' &lt;the file you downloaded&gt;$' SHA256SUMS | shasum -a 256 -c

# or check every artifact you have in one pass
shasum -a 256 -c --ignore-missing SHA256SUMS

If you installed through a package manager

Homebrew, winget, Chocolatey and apt already check a SHA-256 for you before they run anything. You do not need the commands above, but it is worth knowing exactly what that check does and does not prove.

What your package manager checks

Every Bolt package pins the SHA-256 of the installer it downloads, and refuses to proceed if the file does not match. That number is the same one published in the release's SHA256SUMS, so a corrupted or substituted download fails before any code runs.

What it does not prove

A pinned checksum proves the file matches what the package says it should be. It is the package manager's own trust chain, a signed apt repository or a reviewed Homebrew cask, that ties that back to us. If you want a check that depends on neither, run the three commands above against the release directly.

Platform trust, and where it stands

Both platform signing paths are in place. Neither replaces the verification above, which works today and depends on no one else.

macOS Gatekeeper

Signed and notarized by Apple. Both the .app and the .dmg are signed with Developer ID Application: Sparcle Inc. (4VSW7NBZ2S) and carry a stapled notarization ticket. Check it yourself before installing: spctl -a -vvv -t install against the downloaded .dmg reports accepted and source=Notarized Developer ID. The installer tests for a stapled ticket and leaves Gatekeeper's own provenance in place rather than stripping the quarantine attribute, so the operating system's verdict on the file you downloaded stays yours to read.

Windows SmartScreen

Authenticode, through an SSL.com EV certificate. The Windows installer is signed with an Extended Validation code-signing certificate issued to Sparcle Inc. and held in a cloud HSM rather than on a build machine, so the signing certificate names Sparcle Inc. as the publisher. The manifest signature above verifies a Windows download independently of SmartScreen as well.

In-app updates

Updates delivered inside Bolt are separately signed and verified by the app against a key built into it, so an update cannot be swapped even if a release were altered. That is automatic and needs nothing from you.

Verify your download.