Quincey Morris:
On May 6, 2016, at 06:11 , Bernie Maier <apple-xc...@worklists.blurk.net>
wrote:
>
> The OS X project I have inherited builds a framework used by the other
> parts of the app (it's an app with a bunch of plugin bundles). If I try to
> code sign the framework simply by specifying a code signing identity in
> the Xcode build settings for the framework target, the build fails with an
> error saying my code is unsigned when I try to sign it. Looking closely,
> it is attempting to sign foo.framework/Versions/A.
This one might be harder to get a clear answer on.
To start with, can you clarify a couple of things.
— When you say “the build fails”, which target did you ask to be
built? If it’s the app, which target within the build phases did the error
relate to? If it’s the app, what happens if you build just the framework
explicitly?
Good point. I was describing the problem from memory (email machine is
different to build machine) and thus was less than precise.
When I said "the build fails" I was actually describing loosely that I fiddled
(reasonably systematically, but fiddled nonetheless) with attempting to sign
various targets (the framework target in isolation, and the app itself) with
what I inherited in the project, which was a combination of enabling the code
signing identity for the target in the build settings and an explicit run
script build phase with various permutations of an explicit codesign command.
More precisely, I can confirm that one of the things I attempted was to
specify a code signing identity of "Mac Developer" in the target that builds
the framework *and* use a scheme that only builds that framework target. And
building that target on its own fails on the Xcode-generated code signing
step. I won't do a pure copy and paste of the build output, but the gist of it
is:
CodeSign <Xcode-generated path>/foo.framework/Versions/A
cd <project root path>
export CODESIGN_ALLOCATE=<Xcode toolchain path>
Signing Identity: "Mac Developer: Bernie Maier (...)"
/usr/bin/codesign --force --sign <hash> --timestamp=none <Xcode-generated
path>/foo.framework/Versions/A
-------
<Xcode-generated path>/foo.framework/Versions/A: code object is not signed at
all
In subcomponent: <Xcode-generated path>/foo.framework/Versions/A/foo
It is this error that led me (and presumably the previous developers) to add a
run script phase that explicitly signs that code objects, despite the claim in
the tech note that Xcode will build and sign targets inside out.
Now, before I get to the remainder of the questions, I will observe that just
today I decided to try and create a new copy of that framework target. After a
bit of mucking about to get the build settings old enough to work with the old
code I have[1], I attempted essentially the same thing again. That is, build
the target for the framework only, with the same code signing identity
specified. And in this case, the target builds successfully. What is
mystifying me however, is that apparently the code signing command quoted in
the build output is essentially the same as for the failing target, i.e. it is
code signing the framework version A directory.
So, while it looks like I have an acceptable workaround, which is to recreate
the framework target, this smells a little bit like voodoo and I would like to
understand why apparently similar targets would behave so differently.
Specifically, why does an existing target fail to code sign with the same code
signing command as a new target?
Another observation is that, as I described in my first message, the code
signing for the existing framework target succeeds *if* I include a run script
build phase that explicitly code signs the executable within the framework
bundle, i.e. foo.framework/Versions/A/foo
So perhaps my question could also be phrased as, why does code signing
foo.framework/Versions/A in one target fail claiming that the code object
within is not signed at all while code signing foo.framework/Versions/A in the
new target works?
— Is the framework that caused the error (a) a plugin bundle or (b) a
private, embedded framework of the app that’s used by plugins, or (c)
something else?
It's essentially (b). And to be honest, I haven't yet delved into whether it's
at all essential for the framework to be isolated out like that or whether the
app could be re-architected to avoid the plugins. Because for me plugins would
only make sense if there's a need for 3rd-party additions, which I think is
increasingly non-viable for products in a more security-conscious world. But
that's just opinion and conjecture now.
— If this is something to do with plugins, what subdirectory are you
putting them in? The tech note you referred to has a section that’s a sort
of checklist for embedded bundles. Did you do everything it said to do?
The "Nested Code" section? Yes, I believe the project as delivered to me
conforms to that. Specifically, I can see in the built app that the framework
resides in Contents/Frameworks and that the plugin bundles reside in
Contents/Plugins.
Thanks for the clarifying questions. It does help focus me on describing the
issue more correctly.
[1] Mainly turning off ARC, yikes!, there's some modernising work to be done
right there.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
