Pursuit of Simplicity

New to AIR 2 is the ability to create native application installers. By "native", we mean that the installers are not .air files, which the desktop operating systems don't inherently understand, but instead types they do understand: .exe, .dmg, .rpm, .deb.

Applications deployed via native installers do not have access to the Updater API, which is designed to work only with .air files. This is not as restrictive as it might seem, as an AIR 2 application deployed via a native installers has all the facilities it needs to download and launch its own updater.

Applications that take this approach must also take care to secure the download of the update itself. This is handled for you when using .air files and the Updater API. The .air file is signed, and signature validation is performed during the install. None of the contents of the .air file can be executed until after the signature is validated.

The situation is quite different for native application installers: They can generally execute code before signature validation, and may not even be signed. It is therefore critical to make sure that the update you've download is valid before opening it. Otherwise, you'll have created a mechanism that can be hijacked to download and execute arbitrary code.

There are two basic approaches you can use to secure the download path: (a) use an https: download, or (b) sign the download and validate before running. The former is likely easier to set up, but the latter scales better for download support.

If you deploy your application via a native application installer, please take the time to make sure you have a functional, secure update mechanism in place.

As mentioned in my previous post, switching signatures by applying a second signature is a fact of life for updating AIR applications. If you're creating such an update to your application each time you get a new certificate, then you've solved half of the problem. The other half is to make sure you've implemented a matching update strategy in your application.

Unlike the signing half, there's no requirement that each installed application be updated on a regular basis. This would be impossible to enforce, anyway: If a user takes their machine offline for two years, there's little to be done. To successfully install updates over time, however, you do need to insure that the sequence of updates installed on any given machine includes one update for each certificate transition.

For example, suppose you've run through three certificates: C1, C2, and C3. You've got a user who has an older copy of your application signed with C1. To update them to the latest version signed with C3, you need to install two updates on their machine:

1. An update making the transition from C1 to C2
2. An update making the transition from C2 to C3

It'd be more convenient to create an update straight from C1 to C3 but, in a typical case, C1 will be long expired before you obtain C3 and therefore not useable for this purpose.

Since you can't assume the jump from whatever version the user has to the latest version is possible, your update mechanism must provide a method of sequencing updates. That can be as simple as changing the URL used to fetch updates each time you change certificates.

This does not mean you need to have users apply all updates to your application, one by one. For example, suppose you issued three updates to your application after acquiring C2 but while C1 was still useable for applying the second signature: Then you can sign each update twice and any user with a version signed by C1 can jump straight to the latest version signed by C2. Again, what they can't do is jump to any later version that doesn't have the second C1 signature.

In conjunction with regular updates, an appropriate update strategy will keep application updates a seamless experience for your users.

AIR includes an easy-to-use API via which applications can update themselves, and many developers issue frequent updates to their applications. This is not just a good idea: issuing an update at least once each time you renew (or change) your certificate is necessary to maintain the ability to update your application at all.

The issue arises because most code signing certificates are only valid for a limited period of time. (Certificates have to have a limited lifespan in order to keep them secure. The typical lifespan is one year.) Once a certificate has expired, AIR no longer permits it to be used to issue updates to an application. A new certificate has to be acquired, whether as a renewal or as a new purchase.

To secure the transition between those two certificates, at least one update to the application needs to be signed with both certificates, old and new. To facilitate this, AIR does allow the old certificate to be used (for this purpose only) for up to 180 days past its expiration date. In order to issue an update to your application, you must create an update to your application during this period in which both the old and new certificates are valid.

If you fail to create an update signed with both certificates you'll find yourself unable to update the previous version of your application. You can still have users go through a manual uninstall/reinstall process--basically, uninstalling the old application and installing a new one in its place--but that's clearly not as desirable.

To keep this all working smoothly:

1. Replace your code signing certificate when it expires.
   
2. Immediately create an update to your application, signed with both old and new certificates, after receiving your new certificate.
   

Note that you don't necessarily have to publish the update you create each year, at least not right away. You might wait for a planned product release a month or two later, and apply both signatures to that update as well. Creating the update gives you a backup should you need it. More on this in my next post.

It was recently pointed out to me that some applications, which shall remain nameless here, are using File.applicationStorageDirectory to cache hundreds of megabytes of files. Please, don't do this.

The File.applicationStorageDirectory property is intended to provide applications with a guaranteed writable, unique location in which they can save important information, regardless of which platform they're running on. The information is saved to locations that are, on typical machines, backed up. On Windows, it's saved under "<user>/Application Data", which also roams with the user, if roaming profiles are enabled. There's an implicit assumption here that the amount of data being stored is relatively small--megabytes at most.

Large sets of cached files should be stored elsewhere, in locations that aren't backed up and don't roam. AIR doesn't include a handy property for finding such a location, but don't let that stop you; the filesystem API lets you access any location on disk, after all. On Windows, you can use the "<user>\Local Settings\Application Data" directory (note the "Local Settings"); on Mac OS, use "<user>/Library/Caches".

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.