GateKeeper rejects my app in 10.11.4, which was working fine until 10.11.3

I have an app that customers download from the web. This downloaded app was working fine until 10.11.3, my users started seeing an error started with 10.11.4. I havent changed the signing process (or the bundle) between 10.11.3 and 10.11.4. The error that users see is : "MyApp" can't be opened because the identity of the developer cant be confimed.


After a bit of reading about this on Apple developer forums a bit more here are the results:

codesign results are successful

codesign --verbose=4 --deep --strict MyApp.app/

InstallForMacOSX.app/: valid on disk

InstallForMacOSX.app/: satisfies its Designated Requirement

More details on codesign:

codesign -dvvv MyApp.app

Format=bundle with generic

CodeDirectory v=20200 size=240 flags=0x0(none) hashes=1+4 location=embedded

Signature size=8926

Authority=Apple Root CA

Timestamp=Apr 13, 2016, 1:00:14 PM

Info.plist entries=2

Sealed Resources version=2 rules=12 files=1

Internal requirements count=2 size=224


spctl returns an error:This is the same error described in other threads.

spctl --raw -a -t exec -vv MyApp.app

InstallForMacOSX.app: rejected

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>assessment:authority</key>

<dict>

<key>assessment:authority:source</key>

<string>obsolete resource envelope</string>

<key>assessment:authority:weak</key>

<true/>

</dict>

<key>assessment:cserror</key>

<integer>-67002</integer>

<key>assessment:originator</key>

<string>Developer ID Application: My Company (390794875)</string>

<key>assessment:remote</key>

<true/>

<key>assessment:verdict</key>

<false/>

</dict>

</plist>

origin=Developer ID Application: My Company (390794875)


My questions are:

  • Why do I see different results with spctl and codesign ?
  • I checked and our bundle has not been changed since 10.9. Then why is this signed app failing only on 10.11.4 ? (I tried signing the app on 10.11.4, that didnt work either)
  • After reading in detail throught https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG300

    Here is what I am not sure how to do: "If you're told that only apps from the Mac App Store or registered developers can be installed, your app isn't Developer ID-signed. Use the Xcode Organizer to export a Developer ID-signed copy of your app and repeat the test."

    • I have a unique workflow where I dont actually use a Xcode to sign the app, I have a script that signs that app right before it is shipped to the customers. I am not sure how to do this outside Xcode.

I have exactly the same problem (including the -67002 error). Any ideas how to troubleshoot this?

codesign -dvvv MyApp.app

What do you see if you add

--deep
to this command?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 13 Jun through to Fri, 17 Jun. During that time all of DTS will be at the conference, helping folks out face-to-face. http://developer.apple.com/wwdc/

This is performed on OSX 10.11.6 (the bundle was signed on Yosemite):


codesign -dvvv --deep /Users/Giel/Desktop/MyApp.app


Executable=/Users/Giel/Desktop/MyApp.app/Contents/MacOS/MyApp2

Identifier=com.x.x

Format=bundle with Mach-O thin (i386)

CodeDirectory v=20200 size=41941 flags=0x0(none) hashes=2089+3 location=embedded

Hash type=sha1 size=20

CandidateCDHash sha1=6d5d39082c55f2bb3257a5eb4d71ef3be6e6a686

Hash choices=sha1

CDHash=6d5d39082c55f2bb3257a5eb4d71ef3be6e6a686

Signature size=8512

Authority=Developer ID Application: my name

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Timestamp=09 Jun 2016 22:35:26

Info.plist entries=15

TeamIdentifier=x

Sealed Resources version=2 rules=12 files=318

Nested=MacOS/libcgunwind.1.0.dylib

Internal requirements count=1 size=200


Then I tried to sign it again in El Cap, which led to the ‘rejected

source=obsolete resource envelope’ error. Now I get this:


codesign -dvvv --deep /Users/Giel/Desktop/MyApp.app


Executable=/Users/Giel/Desktop/MyApp.app/Contents/MacOS/MyApp2

Identifier=com.x.x

Format=bundle with Mach-O thin (i386)

CodeDirectory v=20200 size=67045 flags=0x0(none) hashes=2089+3 location=embedded

Hash type=sha256 size=32

CandidateCDHash sha1=53d1e256e9aac8d19e6c35bc23e7b0d38d3f9edc

CandidateCDHash sha256=91088e004eeb107408ded0df2285be554d559be4

Hash choices=sha1,sha256

CDHash=91088e004eeb107408ded0df2285be554d559be4

Signature size=8901

Authority=Developer ID Application: my name

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Timestamp=11 Jun 2016 19:57:57

Info.plist entries=15

TeamIdentifier=x

Sealed Resources version=2 rules=12 files=318

Nested=MacOS/libcgunwind.1.0.dylib

Internal requirements count=1 size=200

Nested=MacOS/libcgunwind.1.0.dylib

This seems weird. First, are you sure you need a custom unwind library? Was that put there by your development environment? What development environment are you using?

Second, libraries don’t belong in

Contents/MacOS
, they belong in
Contents/Frameworks
. See Table 3 of Technote 2206 OS X Code Signing In Depth.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your reply.


It's written in Delphi. libcgunwind.1.0.dylib is reuired for the 'standard' unwinding of C exceptions.


I tried moving this dylib to the Contents/Frameworks folder. This doesn't solve the "obsolete resource envelope" problem when trying to codesign the bundle. "codesign -dvvv --deep /Users/Giel/Desktop/MyApp.app" gives the same result (it reports a different dylib path of course).

By the way: I quickly tried this by simply moving the dylib from MacOS to Frameworks. The executable still references the dylib in the MacOS folder.

GateKeeper rejects my app in 10.11.4, which was working fine until 10.11.3
 
 
Q