Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require both Sparkle DSA signature _and_ Apple code signing signature #4

Open
2 tasks
riastradh-brave opened this issue May 8, 2018 · 0 comments
Open
2 tasks
Milestone

Comments

@riastradh-brave
Copy link

In upstream Sparkle, either a Sparkle DSA signature or an Apple code signing signature is sufficient to authenticate an update. This means that the Sparkle DSA key and the Apple code signing key are independent single points of failure, and, e.g., leaking the DSA key through a bad RNG when signing updates would enable distributing malicious updates.

From https://sparkle-project.org/documentation/#apple-code-signing (retrieved 2018-05-08):

If you both code-sign your application and include a public DSA key for signing your update archive, Sparkle allows issuing a new update that changes either your code signing certificate or your DSA keys. Note however this is a last resort and should only be done if you lose access to one of them.

The relevant logic is here: https://github.com/sparkle-project/Sparkle/blob/7a0d402a01646c0b04a9ffa64ccb7b59f592328e/Sparkle/SUUpdateValidator.m#L126-L191

We should consider patching Sparkle to:

  • Pin our Apple code signing identity.
    • This does not mean we can't ever change it. It just means we have to (a) push out an update signed with the old Apple code signing identity first, to add the new Apple code signing identity to the allowed set; then (b) push out a second update signed with the new Apple code signing identity, to remove the old Apple code signing identity from the allowed set.
  • Require both Sparkle DSA signatures and Apple code signing signatures.
    • The danger is that we might lose one of the keys (as in cease to have it, not as in leak it). Solution: keep them both backed up, carefully, in geographically distributed locations, &c.
@RyanJarv RyanJarv added this to the release milestone May 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants