Sparkle
Sparkle copied to clipboard
Update fails when app certificates change
Hey guys,
Is the expected behaviour for the update to fail/say that the update is at the risk of the user whenever i sign version 1.0 with certificate X (which will eventually expire) and then i release 2.0, signed with a new certificate ??
This is more a question than an issue, feel free to move this to the appropriate place !
Thanks
As far as I can tell Developer ID certificates never expire for app users. The expiration affects developer's ability to sign apps, but not user's ability to verify signatures.
Renewals of Developer ID certificates are allowed. If you get a new certificate for the same identity (same Apple account), then all is fine.
Changes of Developer ID identity (new person/company) are not allowed and will be rejected, unless your app archive is also signed with a DSA key, and the DSA key is the same in both old and new version of an app.
On other words, Sparkle supports two types of signatures: DSA and CodeSigning. At least one of them must be valid.
Thanks for the answer @kornelski ! I lost the creds for the former Apple Dev account, so i must sign with new certs in some point in time because i cant renew them. The idea is to also use DSA, got it! Thanks for the help !
@kornelski i have also a couple of questions:
1 - I'm distributing the app as a dmg. I've signed the app and the dmg with my apple dev cert. Do i have to sign both the dmg and the app with the DSA ? Can i use sign_update to do so ?
2 - I'm trying to create a patch (delta update) to apply a new version. Do i have to sign the new app with the DSA, create the delta file, sign the delta file and generate the appcast ? I can't seem to sign the app because it is a directory, do i have to zip it ?
3 - How can i use the generate_appcast ? It's unclear.
-
If you're changing Apple Developer ID identity, both the old version (on users machines) and the new version (update with a new Apple ID) MUST be signed with DSA, and it MUST be the same DSA key.
- By signing app with DSA we mean signing the archive. DSA is applicable only to archive files (dmg, zip, delta).
- When Apple ID changes the DSA key in the old version of the app is the only way to verify it's an authentic update. If you haven't used DSA before for the old version of the app, it will not be possible to update the app. Users will have to trash the app and download a new one from the website.
-
Delta updates always MUST be signed with DSA key. We don't support any other method for delta updates
- your app bundle should still be signed with Apple Code Signing, it's just not sufficient to make a delta update alone.
-
What have you tried?
@kornelski i'm now building the app with all the info i got from the docs, setting up the SUFeedURL and SUPublicDSAKeyFile in the app's plist. Then i'll zip it (instead of using the dmg for now) and will sign with the dsa private key using sign_update. Will also build a new app with a different build number and follow the same procedure.
Then, will put both zip files in a folder and run the generate_appcast. I expect that this generates the appcast for the later version with the delta updates.
Am i thinking this through correctly :p ? (Still waiting on the app to build, will get back tomorrow with real results) !
The certificates situation is understood and it won't be an issue, thanks :)
Sounds OK, but I'm unsure about:
-
Did the previous version of the app that users had already installed on their machines yesterday, include the same
SUPublicDSAKeyFile
? -
Do you have ability to sign the app using your old Developer ID identity that matches identity used to sign your old version of the app that users have already installed?
No, the current live app has no dsa. We will release a major version, so thats not worrying. The first production version to be released (for the new major version) will have dsa, i dont know if we are going to use new certs from a new dev account or the old ones, but they will certainly have dsa :)
Another question !! Can i make a delta from dmg's or i have to use the app ?
Juse keep in mind that all existing copies of the app without the DSA key already in them will reject every attempt of changing Apple ID identity.
Thanks @kornelski , there is no app copy in public domain that we want to update, we haven't released it yet and the first one to be released will have DSA.
I will post my results regarding the deltas. I'm now creating 2 apps (one version 1.0.0.150 and the other 1.0.0.200) with their dmg's (which is what my build system spits out) and will use DSA signing on them. After that, i want to generate the appcast. Can i generate the deltas by placing the dmg's in the same "update" folder instead of the zipped application ???
Thank you very much !
The generate_appcast
tool generates deltas only from the main archive you're going to send to users. Don't put anything else. If you're sending update as a zip, use only zip and don't put dmg there. If you're going to send updates as dmg, don't put any zips there.
Thanks for all the help @kornelski. I created 2 apps with different versions, but adding the DSA made the update fail.
I'm getting the following error: "Sparkle: DSA signature does not match. Data of the update file being checked is different than data that has been signed, or the public key and the private key are not from the same set."
"Sparkle: DSA signature validation failed. The update has a public DSA key and is signed with a DSA key, but the public key desn't match the signature. The update will be rejected."
I generated the keys in a MacOS High Sierra, and it seems to me that the keys are not correct/valid. Is this #1180 ?
Thanks !
It might be. Sorry, I'm unable to verify this right now.
It was indeed the DSA certificates. I generated the DSA certificate using a Sierra machine and it worked just fine. Already configured the app to support delta updated, although i havent tested.
Thank you very much for your help !
@kornelski, thanks a lot for the commit: 5139179487d45fa3cda50ebeea26d67a19e10cba. It solved the problem for me.