Apple® introduced code signing with OS X 10.5 Leopard, which works with the usual model of certificate, signature and trust. Said simply, by signing their applications, developers are able to uniquely identify themselves as the maker of a piece of software towards the operating systems. The identity that becomes attached to the code of a software through code signing is always unique and cryptographically secured. It can't be faked. Code signing also guarantees that the code of the software has not been altered or corrupted.

How OS X uses code signing

OS X uses these attributes of code signing to make itself both more secure and easier to use. To common users, this is most visible in two places:

• The OS X Keychain
  

  A user's passwords, keys and other sensitive information can be safely stored in and retrieved from the OS X keychain by applications. An application that wants to retrieve an entry (= piece of secret information) from the OS X keychain requires the permission to access that entry. It otherwhise can't access that entry. While user's can manage these permissions themselves using Keychain Access.app, they usually don't have to: an application that creates a new entry also automatically is granted access permission to that entry. In OS X versions prior to 10.5, the system had no way to tell whether a new version of Software A comes from the same source as the previous version or whether it was in fact a completely different (and possibly malicious) Software B that only poses as Software A to gain access to secret information previously stored by software A. Users were therefore asked to confirm that new versions of a software get the same access rights to the keychain as previous versions of the software to avoid unauthorized access to secret information.

  Users are still asked to confirm the transfer of permissions in OS X 10.5 for software that hasn't been code signed. Existing permissions from an old version of a software are automatically transfered to new versions of code signed software now, though, as the code signature attaches a unique identity to the code that can now be tracked by the OS.

• The OS X Firewall
  

  With Leopard also came a new firewall with essentially three modes of operation:

  1. allow all incoming connections
  2. allow incoming connections only for essential services
  3. allow incoming connections only to a selection of applications

  In mode 2 and 3, OS X will now ask you for permission when an application want to accept an incoming connection. Users will also be asked for permission for applications that are code signed with a so called self-signed certificate (or even have to add it manually to the OS X firewall list).

  If, however, the application is code signed with a code signing certificate (CSC) issued by a trusted certificate authority (TCA), who have previously verified the identity of the owner of that certificate. If an application is signed with such a certificate (that costs its owner around 300 US$ a year), OS X grants access without asking the user for permission. CSCs issued by a TCA can usually also be revoked by the TCA, so that, when a certificate is abused, it can be invalidated remotely.

So, in essence, it's easier for a code signed OS X application to combine strong security and ease of use. What, however, happens, when an application's code signature is damaged?

Four levels of trust

From what I've learnt thus far dealing with code signing in OS X, it has four levels of trust depending on the code signing status of an application:

Code signing status	Keychain access	Firewall / Incoming connections
Unsigned applications	Users are asked for confirmation on each version change	Users are asked for confirmation on each version change
Signed applications (self-signed certificate)	Permissions are automatically transfered	User are asked for confirmation on first usage of the application
Signed applications (certificate signed by a trusted Certificate Authority)	Permissions are automatically transfered	Permission is automatically granted
Applications with defective code signature	All access to the keychain is blocked	Users are asked for confirmation on every start of the application

How code signing is used in Remote Buddy

To make the life of Remote Buddy users as easy as possible, Remote Buddy is code signed with a certificate signed by a trusted certificate authority. Thanks to this, Remote Buddy's use of the keychain (to securely store the password a user sets for the AJAX Remote) and incoming connections (to serve HTTP requests when enabling and using the AJAX Remote) does not lead to the appearance of OS X confirmation dialogs.

What to do if Remote Buddy informs you that its code signature is damaged

When Remote Buddy's code signature is damaged, Remote Buddy falls in the category "applications with defective code signature" above. It is then no longer able to store or retrieve the password set for the AJAX Remote, nor can Remote Buddy's AJAX Remote start up without user interaction any longer. Starting with version 1.12, Remote Buddy does therefore inform you if its code signature is damaged and - if you click on "More information" - send you to this blog post for more information. Because a damaged code signature means that parts of Remote Buddy can no longer work correctly, users who have such a copy installed are highly recommended to replace their current copy with a freshly downloaded copy. To do this:

1. Quit your current copy of Remote Buddy.app and move Remote Buddy.app to your trash.
2. Download a fresh copy of Remote Buddy.app with intact code signature (Download).
3. Double click the downloaded file RemoteBuddy.dmg.
4. In Finder, drag the contained Remote Buddy.app to your Applications folder and start it from there.

What could have damaged Remote Buddy's code signature?

• The migration of a copy of Remote Buddy that was previously used under OS X 10.4 to OS X 10.5. Why? Under OS X 10.4 Remote Buddy has to modify its own Info.plist in order to allow users to choose whether it should appear in the dock, in the menu or both. Since the Info.plist is included in the code signing as well, any modification of it will break the code signature.
• The use of tools that promise to slim down applications ("MacKeeper", "Clean My Mac" and others). These modify the application bundle, sometimes even the binary itself, which can - or in the latter case - will break the code signature.
• Other modifications made to Remote Buddy.