Re: Code signing, Helper tools/apps, Recent changes
Re: Code signing, Helper tools/apps, Recent changes
- Subject: Re: Code signing, Helper tools/apps, Recent changes
- From: Dragan Milić <email@hidden>
- Date: Fri, 08 Aug 2014 21:20:31 +0200
On pet 08.08.2014., at 02.22, Seth Willits wrote:
> Reading the recent changes in TN2206, the "Nested code" section clearly explains that doing that is a bad idea:
> "… Conversely, putting code into [the Resources folder] will cause it to be sealed as data (resource) files, causing trouble during updates.”
> 1) I'm curious as to what the above warning means. If I verify and assess (on 10.10 DP5) my app that contains signed single-file tools or helper .app bundles in the Resources folder, it passes just fine. spctl accepts it, and codesign --deep validates the app. No complaints. Is it expected to fail?
I’d like to know that too.
> 2) The correct place to put tools and apps bundled inside of a .app seems to clearly be .app/Contents/Helpers. But what about code bundled inside of a framework where there is no Contents folder? The technote seems to suggest if there's a Versions folder (as there is for frameworks) there cannot be a Contents folder next to it. Should it instead be next to the Resources folder? eg: .framework/Versions/A/Contents/Helpers/… ?
I’d suppose the right locations are:
.framework/Versions/A/Helpers/
.framework/Versions/A/PlugIns/
etc (note there’s no “Contents” folder in there). I came up with that idea from the fact that documentation states when signing frameworks not to sign “.framework”, but each particular version "framework/Versions/A”, "framework/Versions/B”, etc, even if there’s only one version of the framework. I can’t be 100% sure that above actually is the case, but the codesign command lead me to that conclusion. While restructuring a huge app project with a lot of helpers, plug-ins and frameworks (which in turn also contain helpers and plug-ins) I did it exactly as stated above. When I did deep verification afterwards with:
codesign --verify --verbose=4 --deep myApp.app
all helpers and plug-ins contained within frameworks were also validated. Except for a third party framework, which has its plug-ins located in ".framework/Versions/A/Plug-Ins”. That gave me an idea to play with locations for a while and putting plug-ins and helpers in other places within a framework bundle resulted in their validation being skipped by the —deep option. The final result for the whole app was still “valid on disk, satisfies its Designated Requirements”, but I still like it much better if everything that is supposed to be validated is actually validated.
Anyway, if you have a third party framework not structured like above mentioned, you should not change locations, that would most definitely break them. Just inform framework developers they need to restructure it.
-- 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