Stop including libchilkatCocoa.a in your shipping product. You will need a new version of Growl, or simply remove that dependency. For an example, see Customizing the Notarization Workflow.
When creating and expanding zip archives for notarisation purposes, always use ditto.
The extended attributes don’t survive this round trip, and thus the code signature ‘disappears’. The problem is that you’re using zip and unzip, which are cross-platform tools that don’t understand extended attributes. One gotcha with storing code signatures in extended attributes is that it’s not uncommon for extended attributes to get dropped. In fact, in most cases it’s a sign that you have a nested code problem. In general we recommend against storing code signatures in extended attributes. $ ls 1 quinn staff 2720 19 Nov 15:14 libUniversalXXX.a That results in the code signature being stored in extended attributes: $ codesign -s "Developer ID App" -timestamp libUniversalXXX.a
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.
For a normal universal Mach-O, the code signature is stored separately in each slice. For a normal Mach-O, the code signature is stored in the Mach-O itself. When you try to sign such a static library, things go a bit wonky. 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.
… (for architecture x86_64): current ar archive random libraryįor universal libraries, the presence of the Mach-O universal container convinces the notarisation system that the file must be code signed. … Mach-O universal binary with 1 architecture: It’s even possible to have a universal static library that contains a single architecture! a extension, so it’s easy to get confused. Universal static libraries are Mach-O universal containers (see ) where each slice is in ar format.īoth of these have the. Traditional static libraries are in ar format (see the ar man page, making sure to look in both sections 1 and 5). Thus, in most cases the correct answer here is to remove the static library from your shipping product.Īs 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: The vast majority of folks who end up shipping static libraries (. Get a version of that framework that’s built against a modern SDK. Remove your dependency on the Growl framework. There’s only two supported ways to fix this: 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. "The binary is not signed for " libchilkatCocoa.a".Ĭould you please help me understand how I can resolve these issues or if there is any workaround for this as I cannot recompile these as they are 3rd party framework. Error "The binary uses an SDK older than the 10.9 SDK" for "amework".Ģ. Now when I try to notarize this app by signing and recompile it, I few errors for 3rd party package "amework" and for a static library " libchilkatCocoa.a".ġ. We have a macOS package that was built 7-8 years back by some other organization.