#FF00AA

When Apple introduced code signing for Leopard, I was doubtful about its benefits (like everyone else seems to be, from what I gather) and worried that it might be a hindrance to all kind of system hacks and customizations — signing the entire app package sure got to help somewhat (but not much) against worms and viruses, but it also means you might break something by just changing an icon file or something (well, maybe the resources themselves are exempt from signing, I’m not sure). So the other day I ran Service Scrubber to tidy up my Services menu a bit, and guess what happened?

Actually, nothing happened for a while. But the next time I restarted Safari (and I don’t have to restart Safari as often as I used to in Tiger, so I’m not sure how much later that happened) it didn’t fill in my passwords anymore. I both blamed the problem on, and circumvented it with, 1Password, so I didn’t pay much attention. But then, the next time I tried to blog something, Safari spun and spun and crashed. When I realized that the browser crashed whenever I tried to access a page locked behind HTTP authentiation, I figured 1Password had somehow corrupted either my keychain or Safari, so I uninstalled it, removed a couple passwords from Keychain Access and tried again… which didn’t improve anything. Still thinking 1Password was the culprit, I looked through the forums, and found out I wasn’t the only one blaming them… wrongfully.

When I disabled the “Search With Google” services in Service Scrubber, it changed something inside the Safari.app package, which changed its checksum so that it didn’t pass the signature validation anymore. And what did OS X do about it? Well, nothing, since Safari still ran and I had no warning anywhere that I could see — only now the application had limited access to the keychain. I reverted the changes in Service Scrubber, and now Safari works again (and I can remove 1Password from the Trash, with apologies).

Moral of the story: users, beware of modifying signed apps; developers, beware of signing your apps. The consequences might not be immediately evident, which makes debugging all the more difficult.

By the way, the Terminal instruction to check whether Safari has been modified is codesign -vvvv /Applications/Safari.app and the manpage justifies the quadruple v thusly:

-v, –verbose -[n]: Sets (with a numeric value) or increments the verbosity level of output. Without the verbose option, no output is produced upon success, in the classic UNIX style. If no other options request a different action, the first -v encountered will be interpreted as –verify instead (and does not increase verbosity).

-v, –verify: Requests verification of code signatures. If other actions (sign, display, etc.) are also requested, -v is interpreted to mean –verbose.

Okay, I’m not sure how the forum poster ended up with four vs rather than two, but still: who the hell develops an Unix program whose command-line parameters change meaning depending on how many times they’re used?