{"id":9313,"date":"2014-08-17T20:46:06","date_gmt":"2014-08-18T00:46:06","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=9313"},"modified":"2014-08-17T23:13:22","modified_gmt":"2014-08-18T03:13:22","slug":"major-changes-to-gatekeeper-in-mac-os-x-10-9-5","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2014\/08\/17\/major-changes-to-gatekeeper-in-mac-os-x-10-9-5\/","title":{"rendered":"Major Changes to Gatekeeper in Mac OS X 10.9.5"},"content":{"rendered":"

Apple<\/a>:<\/p>\n

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.<\/p>\n

Important:<\/strong> For your apps to run on updated versions of OS X they must<\/strong> be signed on OS X version 10.9 or later and thus have a version 2 signature.<\/p>\n

[…]<\/p>\n

Do not use the --resource-rules<\/tt> flag or ResourceRules.plist<\/tt>. They have been obsoleted and will be rejected.<\/p><\/blockquote>\n

Apple does not<\/a> 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<\/a>, which presumably will not be updated?<\/p>\n\n

Daniel Jalkut<\/a>:<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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. <\/p><\/blockquote>\n

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.<\/p>\n\n

Daniel Jalkut<\/a>:<\/p>\n

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.<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

Felix Schwarz<\/a>:<\/p>\n

Currently I have to build parts of Remote Buddy<\/a> in Xcode 3 running on OS X 10.6.8.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

Jeff Johnson<\/a>:<\/p>\n

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<\/b> 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.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

David Hamilton<\/a>:<\/p>\n

If developers don’t act quickly, large numbers of common apps could be affected. Developer John Bafford<\/a> published a command-line script on GitHub Gist<\/a> that identifies the signature version of all programs in a Mac’s applications folder.<\/p><\/blockquote>\n

Including Apple’s own applications, it looks like about two-thirds of the ones I have installed are using version 1 signatures.<\/p>","protected":false},"excerpt":{"rendered":"

Apple: 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[2],"tags":[466,465,30,475],"class_list":["post-9313","post","type-post","status-publish","format-standard","hentry","category-technology","tag-codesigning","tag-gatekeeper","tag-mac","tag-mavericks"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9313","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=9313"}],"version-history":[{"count":6,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9313\/revisions"}],"predecessor-version":[{"id":9330,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/9313\/revisions\/9330"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=9313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=9313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=9313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}