Pursuit of Simplicity

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

AIR 1.5.2 contains a new, performance-related API that heavy users of XML may find handy, System.disposeXML(), that is an instructive example regarding use (and abuse) of the AIR garbage collector.

When an XML document is loaded, it's stored in memory as a graph of individual objects representing elements, text, attributes, and so on. Each pair of related objects--for example, a parent/child element parent--are linked, in the underlying representation, with pointers going in both directions.

This is a convenient representation for traversal, but can be problematic for the garbage collector. As I mentioned in my earlier post about referencing counting and ActionScript objects, the garbage collector will eventually find and discard the entire set of objects after the last external reference is removed. However, it takes more work for the GC than less-connected data structures.

In practice, the amount of time it takes the garbage collector to do its job is related both to the number of allocated objects and the number of pointers between them. So while it is nice that the GC is capable of finding even these highly-connected graphs of objects, using them is also asking it do a lot of work. You can reduce this workload by explicitly disconnecting the pointers between objects.

For graphs of ActionScript objects, you can ease the GC workload by simply nulling out reference between the objects. Note that you don't have to find every last reference for this to be helpful. The GC will still do it's job in the end, and every bit of clearing references helps. For ActionScript objects this can be particularly helpful because, if their reference count then goes to zero, they can be cleaned up even before the GC sweep completes.

XML objects are a trickier case because the API doesn't allow developers to traverse the actual object graph. That's where System.disposeXML() comes in: It traverses the internal object graph backing the XML object, setting all of the internal points to null. Afterwords, the XML object is empty and, presumably, useless. But then, since you were done with it anyway, that shouldn't be a problem.

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.