Posts in Category "install & update"

New Installation and Deployment Options in AIR 3

It is with great pleasure (and a little bit of relief) that I report that AIR 3 will deliver new and much improved installation and deployment options for the desktop. These options enable installation without administrative rights, GPO-based deployment of AIR applications, XCOPY deployment, run-in-place from flash drives, tight binding to specific versions of AIR, and more.

These advantages arise from two new key capabilities:

  1. Captive runtimes. Already used on iOS, this capability allows a copy of the AIR runtime to be embedded with each AIR application. This capability is now supported across Mac OS, Windows, and Android, too.
  2. Custom installers. The application packaging tool, adt, can now be used to generate an application’s file set instead of a complete installer. The file set is a complete copy of the application, capable of being run in place. Or, you can package it up in your own custom installer, whether that’s an MSI for GPO, a PKG for Mac OS, or something else.
For a more comprehensive overview, please see Installation and Deployment Options in AIR 3 on the Adobe Developer Connection.

Disabling AIR Certificate Revocation Checks During Silent Install

Here’s a quick tip that doesn’t seem to be covered in the administrator’s guide for AIR, although it likely should be: You can control how revocation checks are performed during silent installs via the -revocationCheck flag.

When digital signatures are validated, one step in the process involves checking to see if the certificate used to sign has been revoked. This is how certification authorities defend against stolen certificates: they revoke stolen certificates by publishing them in a revocation list; software that validates signatures then checks those lists.

Revocation lists are published to web servers at URLs embedded in the certificates themselves. In order to check the lists, they need to be downloaded. This gives rise to a number of potential questions, like what to do when you are offline and can’t download the latest version. One needs to make a policy decision to answer such questions.

The -revocationCheck flag accepts four values, one for each supported policy:

  • never Don’t check the list, period. No network requests will be issued. (More on this below.)
  • bestEffort Look for a revocation list, but if something goes wrong other than the certificate being revoked, proceed on the assumption that everything is ok.
  • requiredIfInfoAvailable Assuming you can fetch the revocation list, then fail if any later errors occur. But if you can’t download the list at all, proceed as for bestEffort.
  • alwaysRequired If the revocation list can’t be checked without error, don’t proceed.

AIR defaults to “bestEffort”. That’s typically a reasonable choice, and it has the advantage of working both online and offline. But it does mean that for most installations, the AIR installer will at least attempt to issue a network request to download the list. (Lists are also cached, so you won’t always see the request, however.)

Now, there’s one particular case where “never” is a handy setting: Silent installation behind an HTTP proxy that requires authentication. In this situation, so long as AIR issues a network request, the OS will typically pop up a proxy authentication dialog, which of course halts the installation flow and requires manual intervention. To work around it, simply add “-revocationCheck never” to your command line arguments.

Deployment Configuration and AIR Applications

All but the simplest of applications accept, or even require, configuration data that affects their behavior. These settings might affect the appearance of a UI element, an algorithm used to compute a calculation, or where to locate a service, such as a database, required by the application.

AIR developers are often tempted to embed this configuration data into the application package. This appears to be a convenient option because standard methods for deploying AIR applications, whether on the desktop or on mobile devices, don’t provide any alternative way of packaging this data with the application. On the other hand, it is inconvenient if more than one configuration is required, because then a separate package must be created, signed, and managed for each set of configuration options.

I encourage you to avoid packaging configuration options with your application. In addition to creating a package management problem that is otherwise avoided, it makes it impossible to move a copy of the application between different environments, be they test, staging, production, or something else. (Jez Humble and David Farley do an excellent job of covering this issue in their book, Continuous Delivery.)

Instead, I encourage you to deploy configuration data via another mechanism. The simplest approach is to use a file deployed to a well-known location. This approach works well in the enterprise, where it has a well-established history (think /etc on Unix), makes the data easily accessible to AIR applications, and is support by most deployment tools. If you’re in a closed environment your platform of choice might offer other options; Windows, for example, offers Active Directory.

It can be useful, by the way, to have a built-in default set of values, especially in the consumer space. This approach makes it easier for your application to be tested against a mocked up service provider in house and then, when deployed, automatically target the real service. For example, an application that talks to Facebook might use your mocked Facebook service in-house, but when deployed by customers always connect directly to Facebook.

As implied above, Adobe does not provide tools that directly support the deployment of configuration data. The AIR team elected not to enter this space because (a) it’s populated by existing players, such as IBM and Microsoft, with deep expertise in this area, and (b) a significant number of customers we speak with already have an existing solution in place. Our approach, then, has been to integrate with existing deployment tools and their capabilities. For more on this, see Distributing AIR in the Enterprise, by Peter Albert and Michael Labriola.

An Updater Framework for Native Application Installers

In an earlier post about native application installers, I mentioned that implementing an updating mechanism for applications that use this deployment option is currently an exercise for the user, as the updater framework included in the AIR SDK does not support native application installers.

Fortunately, Adobe Platform Evangelist Piotr Walczyszyn has written just such a framework. If you are adopting native application installers, it’s worth a look.

With respect to my earlier comments about securing these updates, it’s worth noting that secure use of Piotr’s framework currently requires hosting HTTPS downloads for the installers.

Application Update Security and Native Application Installers

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.

Update Strategies for Changing Certificates

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.

Update Your Application Regularly

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.

Upcoming Certificate Renewal Changes in Adobe AIR

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.

MAX 2009 Follow-up

Just a quick note to point out that my MAX 2009 talk on AIR distribution and deployment is now available on Adobe TV. Admittedly it’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.)

Find Out About New AIR Deployment Options at MAX 2009

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