Between a rock and hard place, Windows Installer edition

Like most executable binaries on Windows, Windows Installer databases (.msi-files), can be signed with an X.509 certificate to allow verification of origin and integrity.

This is particularly nice on Vista-class Windows systems which during installation show the certificate holder as the verified publisher in the User Account Control consent dialog:

User Account Control consent dialog showing VMware, Inc. as "Verified publisher"

If the executable to be elevated is not signed, the publisher is shown as “Unidentified Publisher”, which may tick some folks off.

That’s all good and well if it wasn’t for Windows Installer Caching, a Pyrrhic feature that originally tried to prevent you from having to search for the Office CD when you want to install a service pack. It more or less caches the installer databases on your computer, so the CD is usually not needed. To make this work reliably, the patches applied to the installed programs have to be cached as well.

Today, this cache is not really optional. Many programs, including the .NET Framework, cannot be correctly updated if the original installers and patches aren’t available in the cache. In my experience, missing cached installers account for many problems with Windows Update. So limiting the size of the cache or deleting it altogether is not a viable option.

What’s worse, installer databases can be manufactured to contain all files to install in an embedded cabinet archive which is quite usually done to enable single-package deployment.

Windows Installer tries to prevent the cache from consuming the entire disk space of the system partition, so up and until Windows 7, this cache only contained the setup information (“meta-data”, if you will), which actually is everything except any embedded cabinet files.

But, to remove the embedded files, the installer database has to be modified, which breaks the publisher’s signature. Now, during uninstall, the UAC consent dialog shows the dreaded “Unidentified Publisher”. Rats!

Stuck between a rock (missing signature) and hard place (enormous disk consumption), Microsoft’s Windows Installer geniuses chose “hard place” and had Windows Installer cache the entire installer database: http://blogs.msdn.com/b/heaths/archive/2009/02/02/changes-to-package-caching-in-windows-installer-5-0.aspx

But they couldn’t resist to screw it up completely: They are caching your entire installer in a location you can’t change, yet still they require the actual source if to install a patch or update the installer feels inclined to do so.

This is bad news for developers of installer packages. Basically, to play nice and prevent the disk space of users from being eaten, installers with embedded cabinets are now discouraged. But then, an installation is no longer a single package. Instead, another packaging step is necessary, as well as an installer bootstrapper that extracts the files and starts the installation.

All of this just to be an “identified publisher”. No wonder code-signing isn’t picking up.

It seems the only solution is to have, instead of a trusted publisher, a trusted online repository (“store”) for the software (“app”) you need to install and maintain.

Advertisements
This entry was posted in Best practices, Coding Horror, Computers and Internet, Software Development and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s