A post on The Switcher’s Blog has appeared concerning Leopard’s new code-signing for applications and the consequences that using slimming apps, such as XSlimmer. According to the post, these utilities break the code signing of applications, thereby breaking their link with the keychain and other security measures. While Safari was used in the post, according to Apple, all applications shipped with the OS are signed, so any app should exhibit the same failure in signing. After slimming my entire Apps folder to one language and architecture (Intel and English), I checked several Apple-supplied applications:
Textedit: Passes as “valid on disk”
Dictonary: Passes as “valid on disk”
Photo Booth: Passes
Mail: Passes as “valid on disk”
iSync: Passes
The issue at hand only appears to occur in Safari, which leads me to believe its not an issue between Code Signing and slimming, and instead an issue with Safari and the way in which it stores is helper apps, making it fail the code check.
UPDATE:I’ve done some tests, and found two other Apple apps that fail after being slimmed. Quicktime Player and iTunes fail after being slimmed, mentioning an error with helper apps contained within them. We’re now pretty confident this is not a slimming issue, and in fact an issue with Apple’s own aplications not following the Dev guidelines on where these helpers belong in order to make code-signing work properly. Chalk it up to another Leopard bug, I guess?
Very interesting. That would coincide with the Apple docs:
http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/chapter_3_section_4.html
Specifically: “each architecture component is signed independently, it is all right to perform universal-binary operations (such as running the lipo command) on signed programs”.
I guess Safari does something special.