What annoyances or real problems may occur when the digital signature of a Mac application is broken?

Applications on a Mac can be digitally signed. When the signature is somehow broken, I know a few applications may notice that. But I don't know in what detail these will be just annoyances or will really break things:

  • The OS X firewall may not be able to correctly set an ad hoc signature, causing one to be repeatedly prompted "Do you want the application '[..]' to accept incoming network connections?"

  • Applications allowed by Parental Controls might no longer run?

  • Keychain Access might be broken?

  • Some say Apple software update might fail. If true, then I wonder if this indeed depends on the Code Signing signature, or would be caused by some non-matching hash for the whole application, or information from BOM files.

More background information below.

Code signing details can be shown using:

codesign --display -vv /Applications/iTunes.app/

...which would yield something like the following (but would not warn about modifications):

Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA

The signature can be validated using:

codesign --verify -vv /Applications/iTunes.app/

Which would yield:

/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement

...or (even when simply putting some extra file in an application's ./Contents/Resources folder):

/Applications/iTunes.app/: a sealed resource is missing or invalid

...or (maybe worse than the above message):

/Applications/iTunes.app/: code or signature modified

Code signing goes back to OS 9 or earlier, but the current implementation was introduced in 10.5 Leopard. Ars Technica writes:

Code signing ties a cryptographically verifiable identity to a collection of code and ensures that any modification to that code is detected. No guarantees are made about the parties involved. For example, if you download an application signed by Acme Inc., you can prove nothing about it except that it came from the same entity claiming to be Acme Inc. the last time you downloaded something from their web site.

This example actually highlights the most useful application of the technology from a consumer's perspective. When upgrading a Mac OS X application today [in 10.4 Tiger, AvB], the user is often prompted to re-verify that this application is allowed to access the Keychain to retrieve usernames and passwords. This seems like a good security feature, but all it really does is train Mac users to blindly click "Always Allow" each time it appears. And really, what is the average user going to do, run the executable through a disassembler and manually verify that the code is safe?

A signed application, on the other hand, can mathematically prove that it is indeed a new version of the same application from the same vendor that you expressed trust for in the past. The result is an end to dialog boxes asking you to confirm a choice whose safety you have no reasonable way to verify.

For the firewall in 10.5 Leopard, Apple explains:

When you add an application to this list, Mac OS X digitally signs the application (if it has not been signed already). If the application is later modified, you will be prompted to allow or deny incoming network connections to it. Most applications do not modify themselves, and this is a safety feature that notifies you of the change.


All applications not in the list that have been digitally signed by a Certificate Authority trusted by the system (for the purpose of code signing) are allowed to receive incoming connections. Every Apple application in Leopard has been signed by Apple and is allowed to receive incoming connections. If you wish to deny a digitally signed application you should first add it to the list and then explicitly deny it.

In 10.6 Snow Leopard, the latter is made more explicit (and can be disabled) as "Automatically allow signed software to receive incoming connections. Allows software signed by a valid certificate authority to provide services accessed from the network".

Mac OS X 10.6 Firewall: Automatically allow signed software to receive incoming connections

(In 10.6, the 10.5.1 options "Allow all incoming connections", "Allow only essential services" and "Set access for specific services and applications" have been revamped into a choice for either "Block all incoming connections", or a list of allowed applications and options "Automatically allow signed software to receive incoming connections" and "Enable stealth mode". Prior to the 10.5.1 update, "Allow only essential services" was actually called "Block all incoming connections".)

For (Apple) applications that somehow have their original signature broken, this ad hoc signature might somehow not be persisted, and is known to have caused trouble for configd, mDNSResponder and racoon.

  • I guess The Tentacle's answer says it all (and no matter how hard I try: breaking signatures has not even shown me a warning for Keychain Access yet). Still, I wonder if anyone has encountered problems. Hope the question is not too long to read... ;-)
    – Arjan
    Oct 4, 2009 at 13:58
  • added certificate tag Oct 4, 2009 at 14:46
  • Nice: someone re-signed the Safari 4 beta (with its tabs on top) to make it compatible with Keychain: see the comments by "petersconsult" at macosxhints.com/article.php?story=20090925131057394
    – Arjan
    Nov 12, 2009 at 20:18

5 Answers 5


An example of where code signing will 'break' an application:

  • Keychain Access.app will not allow you to view passwords if it detects it has been tampered with.

Source: Apple Mailing List and Jaharmi's Irreality

  • Of course, now that you mention it, this is the application I should have used for my very first tests! :-)
    – Arjan
    Nov 18, 2009 at 18:34

What I can tell you is Candybar, the icon customisation app used by quite a lot of people, breaks the digital signature of at least Finder and Dock (and probably some other core system applications) as it changes resource files, and yet so far nothing has been reported as a problem because of this. So an in-the-wild sampling using core OS components would say - not much!

EDIT: here is the result of checking my code signature for my Dock in Snow Leopard:

⚛$ codesign --verify --verbose /System/Library/CoreServices/Dock.app/
/System/Library/CoreServices/Dock.app/: a sealed resource is missing or invalid
/System/Library/CoreServices/Dock.app/Contents/Resources/expose-window-selection-big.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/expose-window-selection-small.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/finder.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/frontline.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_large.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_medium.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/indicator_small.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-l.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-m.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-sm.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/scurve-xl.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/trashempty.png: resource modified
/System/Library/CoreServices/Dock.app/Contents/Resources/trashfull.png: resource modified
  • Aha, I'll investigate that a bit! Some manual changed icons did not break code signing for some other applications. The makers themselves wrote in 2008: As for changing your application icons by hand, you are more than welcome to do so! As a warning: if Apple enables the built-in code signing in a future Mac OS X minor update, your applications will simply no longer launch. This is what we're trying to safely avoid by disabling that feature until we get a sense from Apple of their plans. -- macupdate.com/info.php/id/8948?rord=mod
    – Arjan
    Sep 29, 2009 at 15:58
  • I've added the result after hand-modifying my dock in Snow Leopard... Sep 29, 2009 at 23:37
  • Ah, stupid. So far the only thing I tested was the program icon (by pasting a new icon through Finder's Get Info), not any icon as used by the program itself. Ok, code signing broken for sure. The Candybar developer's comment is still a bit scary to me, but Apple would get a lot of people into trouble when suddenly changing the current (non-)effects.
    – Arjan
    Sep 30, 2009 at 10:20
  • Well the test is to modify resources in a network-facing app and see if breaking the signing stops the automatic passthrough from the application firewall... Sep 30, 2009 at 12:30
  • (Hmmm, the CandyBar developer has removed that January 10th 2008 comment from MacUpdate. Google cache still shows it, but apparently there's a new version for OS X 6.1 so either the problem has been solved, or CandyBar wants to let sleeping dogs lie...? Let's assume there's no issues then!)
    – Arjan
    Oct 7, 2009 at 4:59

A somewhat detailed explanation of code signing in Snow Leopard is provided in ars technica's Snow Leopard review. As far as I can tell, breaking code signing will not really break anything. However, it will cause apps to become untrusted which means having to verify more of their actions.

  • It's actually the 10.5 Leopard review. One nice quote from the 10.6 review though: "And let's not forget the "Mac OS X" technologies that we later learned were developed for the iPhone and just happened to be announced for the Mac first (because the iPhone was still a secret), like Core Animation and code signing." -- arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
    – Arjan
    Oct 5, 2009 at 16:32

I was repairing my Disk Permissions the other day (from Disk Utility), and got this warning:

Warning: SUID file "System/.../ARDAgent" has been modified and will not be repaired.

So there's something that will happen. I don't know how significant that is.

  • Interesting, especially as Apple lists this in "Mac OS X 10.5: Disk Utility's Repair Disk Permissions messages that you can safely ignore" at support.apple.com/kb/TS1448 No word from Apple on how this was changed and why it doesn't matter though... Does codesign --verify indeed show a broken signature?
    – Arjan
    Oct 10, 2009 at 8:23

The current implementation of code signing is pretty toothless and was probably rushed out the door for the benefit of the iPhone developers. Hopefully it will become mandatory at some point in the future, and hopefully it will become a lot easier and cheaper by that time as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .