I recently wrote about problems using Leopard code signing with Mac OS X frameworks. I've since gotten feedback on my bug report. It looks like the problem isn't so much that frameworks can't be signed but that the correct signing procedure isn't documented.
The code signing documentation indicates that bundles should be signed. Frameworks are bundles, so if you're looking to sign your code you'll likely be tempted to sign a framework like this:
$ codesign -s "authority info" Sparkle.framework
But if you do that you run into the confusing situation I encountered, with your framework structure modified and difficulty knowing if the bundle is valid or not.
The feedback I got on my bug report explains that code signing should be done differently for versioned bundles like frameworks and... whatever other versioned bundles there might be. Although frameworks commonly contain only one version, they're designed so that multiple versions can be present. When signing a framework then, you sign the specific version, not the entire framework bundle. So instead of the above, you instead do something like this:
$ codesign -s "authority info" Sparkle.framework/Versions/A
If there are other versions, sign them separately.
This leaves the framework structure unmodified:
$ find Sparkle.framework/ -name Sparkle -exec ls -l {} \;
lrwxr-xr-x 1 tph wheel 24 Nov 29 11:44 Sparkle.framework/
/Sparkle -> Versions/Current/Sparkle
-rwxr-xr-x 1 tph wheel 242928 Nov 29 11:44 Sparkle.framework/
/Versions/A/Sparkle
Of course when verifying the signature, you also need to verify the versions independently of the framework bundle. The framework itself won't have a valid signature, but that's not what you should be looking at anyway:
$ codesign -vvv Sparkle.framework/Versions/A Sparkle.framework/Versions/A: valid on disk $ codesign -vvv Sparkle.framework/ Sparkle.framework/: code or signature modified
This seems to make sense. A framework is designed to allow multiple independent bundles, with symbolic links to indicate which is current. So, sign each bundle on its own.
Mon, 01/07/2008 - 05:54
...phew, i'm glad we cleared that one up ; )
---
hey tom did you know that when you click "More information about formatting options" the window redirects to http://atomicbird.com/filter/tips and you loose your comments
perhaps you might consider implementing target="_blank" (or whatever the w3c xhtml valid code equivalent is) to alleviate this (please)
and finally, for now, do we really need to answer the maths question purely to preview a comment - it wouldn't be so bad if i didn't get "The answer you entered to the captcha challenge is incorrect." when it isn't!
Thu, 04/24/2008 - 06:49
I will be very happy if none of these programs caused the code signing to fail. Sadly that is simply not the case. While you have answered a few emails, my team and I have spent weeks and answered over 2,000 emails about this problem. The errors coming from the Keychain Services API are not consistent and it breaks in several ways, making it very hard to track down the culprit.
Thu, 04/24/2008 - 17:17
I'm afraid I really don't know what you're talking about. None of what programs? I was talking about code signing failing immediately, the first time it was attempted, but now I understand why and what to do about it. What problems are you having with code signing that relate to this post?
I don't believe I've ever received email from you, though since you don't give your name it's hard to be certain. So I don't know what email answers you might be referring to.
Post new comment