I recently signed an update with ADL 1.5.3 using the original publisherID in the app descriptor and 1.5.3 in the namespace. It currently works fine, updating the original app as expected.
The original app was signed using ADL 1.5.1 (or 1.5.2... can't remember). Now lets say 6 months (the grace period) elapses and the client wants to update the app again. I'll need to sign the app WITHOUT a migration signature since the grace period for the original certificate has passed. Will users of the original app be able to update without un-installing if publisherID is specified in the namespace?
I think the answer is no, since that would mean that anyone could spoof anyone's app just by knowing the publisherID. However it's bad user experience to require the un/re-install, and also a pain to develop around (user settings migration from ELS, etc). Can't ADL have some kind of chainmigrate command, where in order to migrate a signature, one could line up certs back to the one that produced the original publisherID?
Once someone has installed the app update signed with the new certificate + the migration certificate, any AIR package signed by the new certificate alone will update the existing installation.
Users who did not install an update signed with the migration signature will have to install such an update first (or use the uninstall/reinstall method). The update with migration signature will remain valid indefinitely unless you disabled the timestamp feature when you applied either signature.
OK, that's clear enough, but it still means the user must have a mandatory update to the application to continue with application updates over the remaining certificate lifetime + grace period, which would almost always be at maximum 18 months, and at minimum, well... a day.
It means that developers who sign their apps close to certificate expiration time only have just over 6 months to produce another update. After that their users will be stuck uninstalling and re-installing an update, which is a lousy option. Or, perhaps as you imply, another option is that the user could install some "intermediate" app whose sole function is to carry the certificate forward, but that implies foresight by the developer to produce such an app before grace period expiration.
I just think we need better options than that. If we had the option to chain the app back to the original certificate that would be best.
Thanks for holding this discussion.
I need your help with regards to signing, certificates renewal and publisher id.
Our team is working on a serious AIR app out there, having a considerable install base. We've now renewed our certificate for the second time, but this time the compiler would generate a different publisher ID. How could that possibly happen, anyone any idea?
Please note, that we've already done that before, we're completely aware that publisher id is generated based on details in the certificate. We also had to renew the previous certificate a couple of times, because different details was causing a different publisher ID. It is totally confirmed that all the details in the current certificate are exactly the same, all of them. But still, the publisher ID is different and that is a nightmare. I'll can share other more complicated explorations further on in the discussion, but this is the first question that needs to be answered.
I can't tell from here why the pub ID would be different. One possibility is that the CA changed the certificate used to sign your certificate.
However, because of issues like these, as of version 1.5.3 (released in Dec '09), AIR no longer bases the publisher ID on the certificate. For situations like yours where you have an existing app, you set the original publisher ID in the application descriptor, sign the updates with a migration signature, and updates will work properly. (New apps should not define a pub ID at all.)
The down side to this is that users who don't update for a long time might have to update to an intermediate version before updating to the latest version. This would happen, for example, if a user had version A installed, but the latest version C, was produced more than 6 months after the cert used to sign A expired. The user would have to first install version B and then C (or do an uninstall/reinstall). You could anticipate this problem with custom update logic, but that does take some forethought.
Thanks Joe, really appreciate your answer and I'd kindly ask you follow this conversation with me.
We're already in the process of checking with Thawte if our certificate has been signed with a different certificate.
We also have tried the 1.5.3 migration approach as suggested: "you set the original publisher ID in the application descriptor, sign the updates with a migration signature, and updates will work properly". Unfortunately it doesn't work. Followed that exactly as described in the Certificate Renewals section of the 1.5.3 Release Notes document http://www.adobe.com/support/documentation/en/air/1_5_3/releasenotes_d evelopers.html
Previous certificate has expired on Jan 18, 2010.
Compiling the build with the migration signature goes well.
Unfortunately, when you launch (double click) the .air file, the AIR runtime attempts a brand new installation, instead of updating the existing one (that is signed with the old certificate).
First, please file a bug against AIR at http://www.adobe.com/go/wish
Second, to rule out some obvious errors:
A. You have set the namespace to reflect AIR 1.5.3 in the application descriptor.
B. When you signed the update you did:
C. The existing installation you are testing has the same publisher ID as specified in the new application descriptor.
D. Can you post the part of your app descriptor where you specify the publisher ID (or PM me)
E. You used the ADT program that came with the 1.5.3 SDK (not an earlier version)
F. The application IDs of the update and the installed version are the same.
We've rulled out possible errors. Actually the test was repeated from the beginning. All your checkpoints are passed.
However, there is some new information that would hopefully help. When the new .air file is built, with the migration signature and everything, it actually doesn't get detected as a brand new application, but it fails to unpack:
Starting app install of file:///Users/triphon/work/triphon_pdc.gugga.com_1666/xxx/head/xxx/ai r/build/xxxMigrated.air
UI SWF load is complete
Unpackaging to /private/var/folders/DE/DEMJRl6mHJK+f9uulQA75k+++TM/TemporaryItems/Fl ashTmp0
unpackaging is complete
application is bound to side-by-side version 1.0
application is bound to this version of the runtime
app id xxxxxxxx
pub id xxxxxxxx
failed while unpackaging: [ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Error #3003" errorID=3003]
starting cleanup of temporary files
application installer exiting
Its totally amazing that the exact same simulation works great, in case we use two active certificates. But with the old build (AIR 1.5.0 namespace), it would get that error.
Any thoughts would be really appreciated.
When you say, "But with the old build (AIR 1.5.0 namespace), it would get that error..." Do you mean the update was built using the 1.5.0 namespace (which wouldn't be expected to work), or that the old, installed version was built using the AIR 1.5.0 namespace?
I apologize for the delay.
Update is always built with the 1.5.3 namespace, it doesn't compile with 1.5.0.
Apparently, the unpacking error that we get is only present on a few computers, for no obvious reason. On most machines it works fine, as well as the migration signature works exactly as expected. That works for us and we are considering the problem resolved.
Thanks very much for your time, it is appreciated!
Europe, Middle East and Africa