Recently in install & update Category

AIR currently secures application updates published with renewed certificates by comparing the publisher ID computed from the old and new certificates. If the publisher IDs are identical the update is allowed; otherwise, it's not.

Recently we've been made aware that the publisher ID computation is flawed in ways that make it quite likely that renewed certificates will not have identical publisher IDs. These range from the trivial to the unresolvable:

• In one case, an original certificate contained a typo in the publisher's identity. This was corrected in the renewal. However, the publisher ID computation requires that the publisher's identity matches exactly.
• In another case, similar, key information changed--but in one of the intermediate certificates in the certificate chain. The change was legitimate, but again fell outside the scope of changes that the publisher ID computation allows.
• In perhaps the most serious issue, the publisher ID algorithm requires that the root certificate in the certificate chain be identical across renewals. Root certificates are typically valid for 20 years or more, so this was not anticipated as a serious limitation. However, many root certificates will be retired in the next few years in favor of certificates with longer key lengths--long before they expire.

If you've run into this situation, you should use the migration signature feature, which was first added in AIR 1.1. It was originally designed to allow secured updates across unrelated certificates (i.e., not renewals). As a general purpose mechanism, however, it also works just as well with renewals, whether or not they run into this issue.

There are, however, two drawbacks to the migration signature mechanism:

1. You have to use the mechanism before your old certificate expires. Certificate renewals are often issued only after the previous certificate has expired.
2. When you migrate between certificates your publisher ID changes. Among other things, this causes the application to lose access to any data stored in the EncryptedLocalStore.

This is an unfortunate turn of events for a feature that was designed to make things easier, and we apologize for the trouble all of this has caused. To address these issues, we will be making two significant changes in an otherwise minor release of AIR. This release is currently scheduled for December. The changes are:

1. Applications will use a specified, not computed, publisher ID. This will allow them to change certificates without losing access to existing data.
2. For purposes of changing certificates, certificates will be accepted as valid for six months after they expire. This allows plenty of time to renew and update the application.

Further details will be made available in conjunction with the upcoming release.

Just a quick note to point out that my MAX 2009 talk on AIR distribution and deployment is now available on Adobe TV. Admittedly t's more like slides-with-a-voice-over than what one would traditionally call "TV". Oh well.

Took some great questions from the audience during the talk. If you have further questions, please post a comment or drop me an email. (My email address is in the last slide of the presentation.)

MAX wouldn't be half as exciting without new stuff to announce, and this year there will be plenty of news. And while developers tend to focus mostly on new APIs when we think about updates to AIR, there are some new deployment options coming, too--options that may enable key new scenarios for some applications. I'll be talking about these new options as well as providing an overview of the existing optios at my MAX 2009 session, "Explore Deployment and Distribution Options for Adobe AIR Applications".

I was recently asked why AIR fetches a Thawte CRL (from http://tss-geotrust-crl.thawte.com/ThawteTimestampingCA.crl) every time an application is installed--even if the application was signed with a certificate from another CA. It turns out there is a good reason for this, and the clue is in the URL itself.

By default, all AIR application signatures are timestamped. Timestamps are created by a timestamp server, and are themselves signatures. When AIR validates the timestamp signature, it downloads the CRL associated with the timestamp signing certificate--just like it would when validating any other signature. And the Thawte timestamp server uses a certificate that--no surprise here--has a CRL hosted by Thawte.

This default is easy to override using the "-tsa" option to the AIR file packaging tool, adt. A value of "-tsa none" turns off timestamps entirely. To specify an alternate timestamp server, specify the URL of that server after the -tsa flag.

For more on AIR code signing, including why timestamping is used, take a look at Code Signing in Adobe AIR.

Interested in checking behavior of an older release of AIR? Or perhaps checking out how seamlessly we effect the upgrade to a newer version? You can download installers for the older releases if you know where to look:

• Mac OS: http://airdownload.adobe.com/air/mac/download/<version>/AdobeAIR.dmg
  
• Windows: http://airdownload.adobe.com/air/win/download/<version>/AdobeAIRInstaller.exe
  
• Linux: http://airdownload.adobe.com/air/lin/download/<version>/AdobeAIRInstaller.bin
  

Substitute an actual version string in place of "<version>", i.e, "1.5" or "1.5.2".