How Sparkle signs Mac app updates, and why it matters
Updated · Dmytro Virych
Guide · 1 min read
Sparkle signs each update with an EdDSA private key kept in your login Keychain, and every installed copy checks that signature against the public key in its Info.plist before installing anything.
Sparkle is the open-source framework most Mac apps sold outside the App Store use for automatic updates. Its security rests on one pair of keys.
The key pair
Sparkle's generate_keys tool creates an EdDSA (ed25519) key pair. Its
documentation says to run it only once, and that it "will generate a private
key and save it in your login Keychain on your Mac". You then add the public
half to your app's Info.plist as SUPublicEDKey.
Every build you ship carries that public key. When the app finds an update in your appcast, it downloads the file and checks the signature against the key it was built with. A file that does not match is refused.
Why this protects your customers
If someone replaced the disk image on your download server, the signature would not match and no installed copy would install it. The key, not the server, is what your customers trust.
The mistake that ends updates
Because the public key is compiled into every copy you have shipped, losing the private key means no installed copy can ever be updated again. A new key would only be trusted by builds made after it. Back the private key up somewhere you will still have in three years, and never commit it.
Two things worth getting right
- One key per product. Sparkle's default is a single key per Mac user account; if you ship two apps, give each its own key, so one leak does not expose both.
- Sign the exact bytes you publish. An appcast entry signed against one file and pointed at a URL that later serves another is reported to every user as a tampered download.
The template does both: a per-product key account, and an appcast entry signed against the disk image exactly as it is published, with a check that the signature verifies before anything is released.