Signed applications are easier to upgrade by Ben Artin

Nov92009

Upgrading an application can be an annoying process. In the best case, you click an Upgrade button and go on with your work; in the worst case, you spend hours in frustration trying to make the new version work. For some applications — such as Fetch — the upgrade experience is made simpler by code signing, a Mac OS X 10.5 Leopard technology.

From the earliest days of Mac OS X, Apple made it easy to securely store passwords in the keychain. A password in the keychain no longer has to be remembered, making it easy for you to log into different accounts, websites, and servers.

An application can only see those passwords that you let it see. The first time an application tries to access a password saved by another application, you have to give it permission. For example, without your permission, Fetch can’t access your bank account password, and Safari can’t access your Fetch passwords.

Before Mac OS X 10.5, every time you upgraded an application, you had to re-approve it for password access. A new version of Fetch would need to get your permission to access your web host password, even though the old version of Fetch already had that permission.

This was because there was no way for Mac OS X to tell a new version from a fake. The fear was not that a new version of Fetch would steal your passwords, but that someone would fool you into installing a Fetch lookalike that emails all your passwords to a miscreant.

Requiring new versions to ask for permissions was a safe thing to do, but it made it rather tedious to upgrade some applications. After you installed a new version, the first time you tried to access a password-protected account, you would see something like this:

“Huh?” you’d say. Change All sounds ominous, given that you were probably just logging in and not yet trying to change anything, but good luck figuring out from that dialog if this was change you could believe in.

Of course, if you click Don’t Change, you’ll get the same question next time. Your computer is giving you a not-so-subtle hint: if you want to get on with your life, you might want to click Change All, whatever in the world that means.

To make matters worse, you wouldn’t always get the same dialog; depending on how you upgraded, you may see a completely different dialog. Even worse, sometimes you might see the dialog once for each password… every time you upgrade.

All in all, this made upgrading confusing and annoying. Nobody was happy about this state of affairs, and, starting with Mac OS X 10.5 Leopard — released in 2007 — Apple made it possible for developers to give the Change All mole one final whack. Using a technology called code signing, information about who created an application can be stored inside the application in a way that can’t be tampered with or falsified.

Once an application contains its author’s identity, Mac OS X can tell the difference between a new version of an application (which has the same author identity as the old version) and a fake (which would have someone else’s identity, or no identity at all). This way, Mac OS X can give new versions of Fetch access to all the passwords that older versions of Fetch had access to. At the end of the day, this is one less reason for having to sweet-talk your computer into letting you get work done.

This is so obviously good for our users that we ran off to sign Fetch two years ago, when we were working on Fetch 5.3, aiming to release it concurrently with Mac OS X 10.5. To gain some other benefits of code signing, we needed to obtain an official code-signing certificate™, issued by an official certificate authority™.

We applied for a certificate, and the issuer conscientiously asked for all sorts of information about the company. Nothing too complicated — company name, company address, a proof that we are a legitimate business, and so on.

This is when we somewhat unexpectedly found out that, while we were busy shipping software, our company ceased to be. Our corporate registration with the New Hampshire Secretary of State had lapsed; before we could proceed, we had to have our status as a legitimate business reinstated. Several months and layers of red tape later, we finally got our hands on a certificate, but by now it was much too late to sign Fetch 5.3 — as planned, we had released it shortly after Mac OS X 10.5 came out.

We signed the next version — Fetch 5.3.1, released in March 2009. Since then, we have been delivering you features and bug fixes without the pesky keychain approval alerts. Enjoy!

Comments

I am honestly interested in why you chose to go to a commercial certificate authority rather than generate your own certificate authority and signing certificate. Can you elaborate?

Histrionic March 25, 2010

Apple’s application firewall is more stringent about certificate checking than most other parts of the OS, and it requires a certificate that is signed by a trusted authority (rather than a self-signed cert). We wanted to support the application firewall so that people can use active mode FTP without being prompted to allow inbound connections to Fetch every time they run Fetch.

Ben Artin March 25, 2010

Page 1

Leave a comment

If you haven’t left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won’t appear on the entry. Thanks for waiting.