New 10.9.5 Gatekeeper rules (and a rant about them changing so often)
New 10.9.5 Gatekeeper rules (and a rant about them changing so often)
- Subject: New 10.9.5 Gatekeeper rules (and a rant about them changing so often)
- From: Dragan Milić <email@hidden>
- Date: Tue, 05 Aug 2014 20:20:42 +0200
Hallo all,
If you’re a member of Mac Developer Program (which I believe most of you here are), you received a message from “Apple Developer” yesterday, which explained changes in the way Gatekeeper in upcoming 10.9.5 and 10.10 DP5 will recognise signed app. If you don’t re-sign your apps, they will be treated as coming from “unidentified developer”, even though you used your 3rd party developer certificate/signID (I’m talking about non-MAS applications here). In short, one should use 10.9+ (and Xcode 5+) to create v2 signatures, which is something we started doing since Xcode 5. But there is one additional thing that affects me, and that’s "The --resource-rules flag and ResourceRules.plist are not supported".
I’ll try to explain my particular situation, with a hope someone can tell me the solution. My project is a HUGE application, which contains of A LOT of other sub-projects, and they all have complex interrelations and dependencies. Those sub-projects are plug-ins, frameworks and some tools (plain executables). As part of building the application, all sub-projects are built accordingly and everything works fine.
Build/compile options common to all sub-projects (and the main app project) are located in a single configuration file, used by all (sub)projects. To make advantage of using Xcode for signing and creating v2 signatures (and not doing it by hand using codesign utility), which is actually the recommended way, there’s the following line in the configuration file:
CODE_SIGN_IDENTITY = Developer ID Application: MyFirstName MyLastName
It all works as expected, I just need to additionally re-sign some 3rd party frameworks and I do it in the “run script” build phase of the main application project, after those frameworks are copied in the main application bundle. So, pretty standard configuration so far.
Now, I don’t want any header files from internal frameworks in the final application bundle, so I remove them all in the same “run script” build phase of the main application project. Consequently, this breaks signatures (spctl —assess reports “missing sealed resource”) and therefore I use --resource-rules option of codesign. So, I added this line into the common configuration file:
CODE_SIGN_RESOURCE_RULES_PATH = $SRCROOT/../Configurations/CodeResourceRules.plist
and in that “CodeResourceRules.plist” file I specified all headers files to be optional when verifying signature. Xcode takes care of resource rules automatically, while I manually use that option in the “run script” phase for above mentioned 3rd party frameworks.
But now, I’m not allowed to use the --resource-rules option. I tried on 10.10 DP5 and spctl reports "Foo.app: rejected, source=obsolete resource envelope” as expected :-( When trying to open the app, Gatekeeper tells me it comes from unidentified developer. If I remove --resource-rules option, I get "Foo.app: rejected, source=missing sealed resource”, again as expected as header files existing during the signature process are now missing.
The first “solution” (if that’s it at all) is to keep header files in the internal frameworks, which I really don’t like. The second one is to remove above mentioned lines from the configuration file and add “run script” build phase for EVERY sub-project (there are about 65 of them) and sign EVERY particular executable, resource, script etc. But that would completely defeat the purpose of using Xcode to sign bundles, and I don’t even know whether if would create valid v2 signatures.
I’ve read couple of times everything I could find in documentation about Gatekeeper, codesign and code signing in general and I couldn’t figure the way out of my situation. Does anyone else have some suggestions?
Cheers,
-- Dragan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden