Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Adopt standard code signing in favor of DSA signing #48

andymatuschak opened this Issue · 3 comments

1 participant


**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-06-29:*

We should use code signing for 10.5+ applications; it's in the system,
and this way, devs who already sign their apps won't have to do double


**Andy Matuschak (andymatuschak)* wrote on 2008-08-17:*

We should investigate the use of CDSA for 10.4 compatibility:


**James W. Walker (jw-jwwalker)* wrote on 2008-08-17:*

When I looked at the code signing stuff, I didn't see any public API to
verify a signature, only a command line tool. That might be less
convenient for Sparkle.


**Hofman (cmhofman)* wrote on 2008-09-15:*

I don't think a command line tool would be a problem, it's easy to run
it using NSTask.

The initial reason that code signers don't have to do double work is not
true, because what should be signed is the downloaded archive/disk
image/package, not the bundle (an installer can be just as malicious, if
not more so, than an app).

@andymatuschak andymatuschak closed this issue from a commit
@andymatuschak andymatuschak Fixes #48: Adopt standard code signing in favor of DSA signing
Thanks to Mattt Thompson (@mattt) for tag-team-ing this with me.

With this change, if your app deploys only to 10.6+, then you can
dispense altogether with the DSA signatures on future updates to your
application: just make sure the "to" version satisfies the "from"
version's Apple code signing requirements. Most of you are probably
already doing that, and if you're not, you should be anyway.

Specifically, Sparkle validates the designated requirement of the "from"
version against the "to" version. By default, as of this writing, that
means that the bundle identifiers must be the same, and that the leaf
certificate of the signature is the same. So if you keep code signing
your app with the same cert, Sparkle will Just Work without any
additional DSA signature nonsense for you to deal with.

Traditional Sparkle DSA signatures will still be honored.

This support has only been extended to updates to the main app bundle.
If you're updating some other bundle, you will have to use DSA signatures
to secure your updates in the future.

***IMPORTANT: previously, Sparkle considered an update "safe" if both the
appcast and update were distributed over https. That is nowhere near as
strong a verification measure as code signing or the old-school DSA
signatures, so with this change, support for unsigned, https-distributed
updates has been removed. If you're targeting 10.6+, start code-signing
your apps if you haven't already, and everything will be fine. If you're
targeting earlier OS Xs, you'll need to start adding DSA signatures to
your appcasts. When you link this changed version of Sparkle into your
app, it will warn you on launch if you are not code signed and do not
have a DSA public key specified in your Info.plist.
@vslavik vslavik referenced this issue in vslavik/winsparkle

Add support for DSA signed updates #23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.