OK, let’s tackle your problems in order.
There’s really not much you can do here. Notarisation requires modern code signing and, in order to be guaranteed that it has modern code signing, it requires that your components link with the 10.9 SDK or later. There’s only two supported ways to fix this:
The vast majority of folks who end up shipping static libraries (
.a
files) to end users do so by mistake [1]. Thus, in most cases the correct answer here is to remove the static library from your shipping product.
As to the actual symptoms you’re seeing, I looked into the situation with static libraries just yesterday as part of a DTS incident and thus I can explain the observed behaviour:
Static libraries come in two flavours:
Both of these have the
.a
extension, so it’s easy to get confused. It’s even possible to have a universal static library that contains a single architecture!You can tell these apart using
file
:
$ file libXXX.a
… current ar archive random library
$ file libUniversalXXX.a
… Mach-O universal binary with 1 architecture: [x86_64:current ar archive random library]
… (for architecture x86_64): current ar archive random library
.
For universal libraries, the presence of the Mach-O universal container convinces the notarisation system that the file must be code signed. It’s not clear to me whether’s that good or bad choice, and I’ve escalated that analysis to Apple’s R&D engineering (r. 57321912).
When you try to sign such a static library, things go a bit wonky. For a normal Mach-O, the code signature is stored in the Mach-O itself. For a normal universal Mach-O, the code signature is stored separately in each slice. However, there’s no place to store a code signature in a static library, and so a static library ends up being signed as data, not code. That results in the code signature being stored in extended attributes:
$ codesign -s "Developer ID App" --timestamp libUniversalXXX.a
$ ls -l@ libUniversalXXX.a
-rw-r--r--@ 1 quinn staff 2720 19 Nov 15:14 libUniversalXXX.a
com.apple.cs.CodeDirectory 130
com.apple.cs.CodeRequirements 168
com.apple.cs.CodeRequirements-1 166
com.apple.cs.CodeSignature 9003
In general we recommend against storing code signatures in extended attributes. In fact, in most cases it’s a sign that you have a nested code problem.
One gotcha with storing code signatures in extended attributes is that it’s not uncommon for extended attributes to get dropped. This is what’s happening in your case. The problem is that you’re using
zip
and unzip
, which are cross-platform tools that don’t understand extended attributes. The extended attributes don’t survive this round trip, and thus the code signature ‘disappears’.When creating and expanding zip archives for notarisation purposes, always use
ditto
. For an example, see Customizing the Notarization Workflow.
So, to summarise:
You will need a new version of Growl, or simply remove that dependency.
Stop including
libchilkatCocoa.a
in your shipping product. That static library is meant as an input to the linker, not to be distributed.If you come across a static library that is meant to be distributed, the notarisation story is nuanced and we should discuss the details.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
[1] There are some third-party development environments that include static libraries as part of their runtime, but that doesn’t seem to be what’s happening here.
