Posts in Category "install & update"

Why AIR fetches a Thawte CRL no matter who signed your app

I was recently asked why AIR fetches a Thawte CRL (from 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.

Downloading Historical Adobe AIR Releases

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:<version>/AdobeAIR.dmg
  • Windows:<version>/AdobeAIRInstaller.exe
  • Linux:<version>/AdobeAIRInstaller.bin

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

Revised AIR 1.5.2 Application Install Experience

The Adobe AIR 1.5.2 release is now available. There are relatively few changes in it, given that it’s a minor release, but I’ll nonetheless be posting a few entries about the more interesting changes.

Perhaps most interesting of all is that we’ve revised the much-loved unrestricted system access warning that’s displayed during application install. I think you’ll be pleased with the new design:


Please note that this change applies only to applications signed with certificates that are trusted on the targeted machine. I hope you’ll find some comfort in knowing that we do, indeed, listen to–and appreciate–your feedback.

MAX 2009: AIR Deployment and Distribution Options

At this year’s MAX conference I’ll be speaking on deployment and distribution options for AIR applications. Here’s the description:

Learn how to get your AIR applications to your users and how to keep them up to date. We will discuss important considerations for distribution on the Internet or an intranet, including impacts on your auto-update mechanism. We will cover existing deployment options such as badge installation and IBM Tivoli support. Finally, we will explore the new deployment options that will be available in Adobe AIR 2, including the native installer support required to use some of the advanced new AIR 2 APIs.

My favorite part of MAX is hearing directly from you. If you’re there, I hope you’ll stop by and say hello.

Upgrade Codes, Product Codes, and Silent AIR Application Uninstall

Those who sign up for the Adobe AIR redistribution license have had the ability to silently install and uninstall AIR applications since the AIR 1.0 release. Unfortunately, the silent uninstall support on Windows is a bit rough. I’ve included below a link to a utility I wrote that eases the problem a bit. But first, a little background on the issue.

When an AIR application is installed on Windows, it’s installed via Windows Installer. This is a good thing; it allows leveraging all the capabilities of Windows Installer. For example, silently uninstalling an AIR application on Windows can be accomplished directly via the “msiexec” utility that is part of Windows. All you need to provide to msiexec is the product code of the application.

AIR applications don’t inherently contain product codes—they’re specific to Windows Installer—and you won’t, for example, find one in your application descriptor. Furthermore, Windows Installer requires that product codes change—even for the same application—under certain circumstances. In order to play it safe, AIR generates a unique product code for each version of your application. This, in turn, means you need to know the product code associated with the specific installed version of the application in order to uninstall it. This is a hassle.

Fortunately, Windows Installer also associates an upgrade code with each application. An upgrade code is basically an application identifier that never changes and, given an upgrade code, you can look up the corresponding product code. The mapping from upgrade code to product code is stored in the registry at application install time. Like product codes, AIR generates an upgrade code for your application. Unlike product codes, upgrade codes are the same across all versions of your application and are easily determined via the OSID application that comes with the redistribution support.

Unfortunately, the only way to look up that mapping is via the MsiEnumRelatedProducts() system call, and the msiexec utility won’t do it for you. (Theoretically you can look this mapping up yourself in the registry, but that turns out to be fairly complicated, and I’m not sure it can be done reliably.)

How much of a problem this is depends on the uninstall technology you’re using, whether or not it can perform this lookup for you, and whether or not you’re in a position to write a few lines of C code to perform the lookup. For anyone out of luck on all counts—or just curious—I’ve written a small utility called “msiu2p”. You can download msiu2p here. (The zip package includes the executable and the source.)

Here’s an example:

c:\ msiu2p {8DA920D5-C41C-42E0-BF31-87BA49984EE4}

Of course this isn’t useful just for AIR applications, either: It’s a handy complement to msiexec for any application using Windows Installer.

We plan to improve AIR’s intrinsic support for this kind of thing in an upcoming release. In the meantime, I hope this utility will help fill the gap for those who need it.

Should AIR Support Application Installs Without Admin Rights?

In my previous post, I explained that installing an AIR application sometimes requires admin rights. This begs the question: Should AIR take pains to avoid those parts of application install that sometimes require admin rights? Some applications do support this, including recently Google Chrome.

We considered this when designing the AIR install experience and ultimately decided this would be a mis-feature. It breaks down to two cases:

  1. You’re the admin for the machine on which you’re installing software. (This is the typical consumer scenario.) You don’t need to install without admin rights because you’ve got them.
  2. You’re not the admin, and you don’t have admin rights. You want a non-admin-rights install because otherwise you can’t install the application. (This is a typical enterprise scenario.)

In this second case, however, your machine is locked down for a reason: the admin doesn’t want you to install anything. If they knew you were avoiding this restriction by installing without admin rights, they’d probably close that loophole, too. See, for example, this article about stopping users from installing Google Chrome.

So any specific support in AIR for installing applications without admin rights would be temporary at best, as admins could still prevent it. Worse, it makes extra works for admins who have to jump through hoops to keep their machines locked down. Since we’re interested in making sure AIR stays friendly for enterprise deployments, and this feature has no value for non-enterprises, well, it just doesn’t seem to make much sense.

What are Administrative Rights, Anyway?

Installation and deployment discussions often use the term “admin rights”, as in, admin rights are required for this, or admin rights aren’t required for that. But what are admin rights, really?

The answer is, it depends. For most purposes, admin rights can be loosely defined as being the set of rights granted to either a root user (Linux, Mac OS) or an administrator account (Windows).

Still, that leaves plenty of gray areas. First of all, rights can also be divided topically. For example, an account might have rights to install software, but not alter the network settings. Does that account have admin rights? Some of them, I guess.

Second, access can be granted in other ways. For example, file permissions might be set on your Mac OS machine such that any user can install software to /Applications. Does this mean all users on the machine have admin rights? That they’re all admins on this machine? Or just that installing sofware on this machine isn’t considered an administrative task?

To further complicate matters, even the task at hand might not always require the same rights. For example, installing software into a user’s directory (i.e., Documents and Settings) might require a completely different set of permissions than installing it into a machine-wide location (i.e., Program Files). Or, the machine could be configured so that both operations require the same permissions.

The term gets used loosely because, most of the time, these gray areas can be safely ignored. But when someone asks if your software requires admin rights, well, it might pay to ask what they mean by that.

ChosenSecurity Individual Developer Certificates

Most certification authorities will issue certificates only to businesses. This can be a drag for individuals publishing applications on their own. If you’re in that camp, you may want to take a look at ChosenSecurity’s AIR code signing certificates, which are available to individuals.

No, I’m not receiving anything from ChosenSecurity for posting this.

Installers Can Only Do So Much

In my response to my earlier post about why uninstallers don’t clean up user files, commenter dan suggests that uninstalling and then installing an application should erase application settings. He argues that this would at the very least help users who have applications that don’t work because, for example, the application settings have become corrupt.

The fix is tenuous at best:

  • It won’t work if the application doesn’t opt in. After all, some applications will want to save those settings.
  • It won’t work if AIR can’t determine where the settings are stored. Yes, we provide a location for that—but it’s a suggestion, and not obligatory.
  • It requires the user to intervene (uninstall/reinstall) to fix a problem the application could address for itself.

The point about corrupt user settings is valid; this can happen and effectively disable an application. And I agree, asking users to find the file containing these settings and manually delete them is unreasonable. But the truly simple fix is to code your application so that it can detect and ignore corrupt settings. Get that right, and users may never even realize something went wrong.

More on AIR Enterprise Deployment

Peter Albert and Michael Labriola have written a new article for the Adobe Developer Center: Distributing AIR in the Enterprise. It describes how to deploy AIR and AIR-based applications in the enterprise via:

  • Microsoft Systems Management Server,
  • Microsoft System Center Configuration Manager, and
  • IBM Tivoli Provisioning Manager Express.