Major Changes to Gatekeeper in Mac OS X 10.9.5
Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.
Important: For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature.
[…]
Do not use the --resource-rules flag or ResourceRules.plist. They have been obsoleted and will be rejected.
Apple does not seem to have given any reason for why such a big change—breaking many third-party applications—is so important that it needs to be introduced in a maintenance update of the OS. Is there a danger for people using 10.6–10.8, which presumably will not be updated?
I’ve been burned too many times by default code signing behaviors, so I long ago switched to an approach which many will consider too complicated, but which has nonetheless saved my bacon on repeated occasions. The “resource rules” change from Apple wouldn’t have even registered on my radar, because the final code signing of all my bundled frameworks, plugins, XPC services … every darned executable, is controlled by a custom build phase which is run very late in my apps’ build process, right before the final code signing of the overall app that Xcode handles at the very end.
[…]
A common kind of customization you might want to make is to e.g. add arguments to codesign that will cause the preservation of entitlements, so that e.g. an XPC service with its own entitlements will not have those blown away by your re-signing of the app. See “man codesign” for more information about the “-preserve-metadata” option and other flags.
I take this a step further and do all of my code signing in a shell script that runs after Xcode finishes its build and my other build scripts have run. It’s annoying to have to maintain this script, but the alternative—leaving it to Xcode’s built-in code signing support—has never seemed to work. A version-controlled script lets me see exactly what’s happening and in what order. I’m less subject to Xcode’s whims and can easily share logic among my applications.
However, for a variety of reasons many of us either need to build with older versions of Mac OS X or Xcode. We face a conundrum that can be solved by signing (or more accurately, re-signing) the apps on 10.9, ensuring that the signature is up to snuff even if the code was compiled and the app was assembled with earlier tools.
This is a fairly straight-forward process, but there are some gotchas and you should be aware of what effect running codesign with various flags will have on your finished product.
[…]
In my tests I ran into some issues having to do with the fact that some of my apps have custom “designated requirements.” I have ironed out all the kinks yet but it seems to help in this scenario to re-establish all the code signing for the bundle first and then as a final icing on the cake, re-sign the app package with the custom designated requirement.
Currently I have to build parts of Remote Buddy in Xcode 3 running on OS X 10.6.8.
[…]
The only way to obtain a v2 signature is by code signing under 10.9, but since Xcode 3 doesn’t run on anything newer than 10.6.8, I’ll have to separate the build process from the signing, packaging and submission process.
As TN2206 indicates, custom resource rules no longer work on 10.9.5 or Yosemite Developer Preview 5. The effect, for us, is that none of our shipping apps will currently be accepted by Gatekeeper on those versions of OS X. This was quite a shock. Fortunately, there is a “happy” ending to the story. We needed a solution to the problem quickly, and ideally a solution that didn’t require us to completely rearrange our source code repository. The potent combination of desperation and brilliance, if I may be so modest, led me to the solution.
[…]
I’m not going to make any editorial comments here on the change to Gatekeeper in 10.9.5, because this post is intended for developers, to aid them in their work. And my comments would be NSFW.
If developers don’t act quickly, large numbers of common apps could be affected. Developer John Bafford published a command-line script on GitHub Gist that identifies the signature version of all programs in a Mac’s applications folder.
Including Apple’s own applications, it looks like about two-thirds of the ones I have installed are using version 1 signatures.
6 Comments RSS · Twitter
I too use a build script that includes code signing. I have always considered Xcode as simply one of the tools used for building my apps: the biggest and most important one, but not the "master" tool. Some tasks are not easy or impossible using Xcode: version control, bundle modifications, code-signing, etc. It is a design issue: Xcode is a good IDE and a good build tool, but is optimized for the standard app-building workflow, and does not accomodate deviations from this workflow very well. The 'Run Script' phases are the only way to add custom behavior but are cumbersome to write and debug. And even then, you can't do things like build the app from a specific git commit: you have to go "above" Xcode. A build script is a solution to all this. Code (re)signing is then naturally part of that build script.
Well, maybe I should install 10.9.5 before bragging too much.
Well, that explains that.
Love how the iCloud master keys were also vulnerable.
Nothing wrong with having everyone's machines admin'd from Cupertino. Nope. Nothing wrong with that at all.
No, Chucky, the tweets are an obvious hoax, and the TUAW "reporting" is complete garbage. Anyone with half a brain would realize that if Apple's Developer ID keys were stolen, then Apple would have to revoke our Developer ID certs, issue us new ones, and have us re-sign our apps with the new certs. That's how PKI works. But no such thing has happened or is happening. We're signing the apps with the same old certs as before. Not to mention that the so-called "security expert" quoted in the article is actually a "journalist" with no security expertise whatsoever. Check out his LinkedIn profile, which is easily googled. It's pathetic that the "media" resorts to publishing tweets instead of doing actual investigation and research. And it's also pathetic that people can't detect BS when they see it.
