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.