Skip navigation
tedalde2
tedalde2
Currently Being Moderated

How long can the same publisher ID be used to update an app

Jan 4, 2010 7:38 PM

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?

1263 Views   11 Replies   Latest reply: stefanyotov, Mar 15, 2010 7:49 AM
 
Replies
  • Joe ... Ward
    Currently Being Moderated
    1. Joe ... Ward,
    Jan 5, 2010 12:34 PM   in reply to tedalde2
    Report

    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.

     
    |
    Mark as:
  • tedalde2
    Currently Being Moderated
    2. tedalde2,
    Jan 5, 2010 5:25 PM   in reply to Joe ... Ward
    Report

    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.

     
    |
    Mark as:
  • tzeng
    Currently Being Moderated
    3. tzeng,
    Jan 8, 2010 10:54 AM   in reply to tedalde2
    Report

    We did a research on how developers renew their certificates and come to the current implementation as a good compromise.

     
    |
    Mark as:
  • stefanyotov
    Currently Being Moderated
    4. stefanyotov,
    Feb 24, 2010 11:11 AM   in reply to tzeng
    Report

    HI Guys,

     

    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.

     

    Please reply.

     

    Kind Regards

    Stefan Yotov

     
    |
    Mark as:
  • Joe ... Ward
    Currently Being Moderated
    5. Joe ... Ward,
    Feb 24, 2010 12:53 PM   in reply to stefanyotov
    Report

    Stefan,

     

    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.

     
    |
    Mark as:
  • stefanyotov
    Currently Being Moderated
    6. stefanyotov,
    Feb 25, 2010 12:07 PM   in reply to Joe ... Ward
    Report

    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).

     

    Please advise!

     

    Thank you

    Stefan

     
    |
    Mark as:
  • Joe ... Ward
    Currently Being Moderated
    7. Joe ... Ward,
    Feb 25, 2010 1:41 PM   in reply to stefanyotov
    Report

    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:

    1. Created the AIR package using the NEW certificate
    2. Used the ADT -migration command with the OLD certificate

     

    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.

     
    |
    Mark as:
  • stefanyotov
    Currently Being Moderated
    8. stefanyotov,
    Mar 1, 2010 5:05 AM   in reply to Joe ... Ward
    Report

    Thanks Joe,

     

    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

    UI initialized

    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.

     

    Thanks again

    Stefan

     
    |
    Mark as:
  • Joe ... Ward
    Currently Being Moderated
    9. Joe ... Ward,
    Mar 1, 2010 10:22 AM   in reply to stefanyotov
    Report

    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?

     
    |
    Mark as:
  • tzeng
    Currently Being Moderated
    10. tzeng,
    Mar 1, 2010 5:34 PM   in reply to stefanyotov
    Report

    Hi Stefan,

     

    We would like to help you to figure out what the problem could be. I have sent you an email to ask for more info.

    Could you take a look at my email?

     

    Thanks,

     

    -ted

     
    |
    Mark as:
  • stefanyotov
    Currently Being Moderated
    11. stefanyotov,
    Mar 15, 2010 7:49 AM   in reply to Joe ... Ward
    Report

    Hi Joe,

     

    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!

     

    Stefan

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points