Binary is improperly signed

Hi,

I develop a MacOS application that has been being successfully distributed for several
years. Recently (I think following the 10.15.6 update) it began failing to start after
signing. It runs ok on my dev machine without signing.

% open ./path/to/MyApp.app
LSOpenURLsWithRole() failed with error -10810 for the file /path/to/MyApp.app.

The system.log indicates an issue with the signature.

Aug 11 10:57:28 mbp2019 com.apple.xpc.launchd[1] (*.*.*.109024[20001]): removing service since it exited with consistent failure - OSREASONCODESIGNING | When validating /path/to/MyApp.app/Contents/MacOS/MyApp:
Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements:
Aug 11 10:57:28 mbp2019 com.apple.xpc.launchd[1] (*.*.*.109024[20001]): Binary is improperly signed.

However no issues are reported when verifying the signature.

% codesign -dv --verbose=4 -r- /path/to/MyApp.app
Executable=/path/to/MyApp.app/Contents/MacOS/MyApp
Identifier=*.*.*
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=612 flags=0x10000(runtime) hashes=10+5 location=embedded
VersionPlatform=1
VersionMin=657152
VersionSDK=658176
Hash type=sha256 size=32
CandidateCDHash sha1=53994a8bacf921809f8c3dd224b9537a48fa6fa1
CandidateCDHashFull sha1=53994a8bacf921809f8c3dd224b9537a48fa6fa1
CandidateCDHash sha256=8c0c0b984cfa0f037b90b32fd2934fa806a3c40e
CandidateCDHashFull sha256=8c0c0b984cfa0f037b90b32fd2934fa806a3c40ef3d064a4c05ed9d968eb5ce0
Hash choices=sha1,sha256
CMSDigest=6024afb1b3d39417d6a4beb25d0fb021717750af26f51ad3acde6269723c698f
CMSDigestType=2
Page size=4096
CDHash=8c0c0b984cfa0f037b90b32fd2934fa806a3c40e
Signature size=9070
Authority=Developer ID Application: * *** ***. (XXXXXXXXX)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=11/08/2020 at 10:57:06 AM
Info.plist entries=9
TeamIdentifier=XXXXXXXXX
Runtime Version=10.11.0
Sealed Resources version=2 rules=13 files=394
designated => identifier "*.*.xxxx" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = XXXXXXXXXX

% spctl --assess -vvv /path/to/MyApp.app
/path/to/MyApp.app: accepted
source=Developer ID
origin=Developer ID Application: *** *** *** (XXXXXXXXXX)

entitlements.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<removed-for-forum>/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key> com.apple.security.device.usb</key>
<true/>
</dict>
</plist>

How do I find out what the issue is?

Up vote post of glennra Down vote post of glennra
2.0k views
Posted by
glennra
Reply
Add a Comment

Replies

entitlements.plist:

FYI, the entitlements in this plist are only one input to the code signing process. If you want to see what entitlements your code is signed with, use:

Code Block  
% codesign -d --entitlements :- /path/to/your.app


As to what’s causing your app not to launch, it’s hard to say based on the info provided. To start, I recommend that you do this:

Code Block  
% codesign -v -vvv /path/to/your.app


to check the the code signature is actually valid. You should then dump the entitlements of your app (as per above) and your embedded provisioning profile to make sure that any restricted entitlement is allowedlisted by the profile.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
Thanks for that. The results from the above commands are:

Code Block sh
% codesign -v -vvv path/to/myapp.app
path/to/myapp.app: valid on disk
path/to/myapp.app: satisfies its Designated Requirement


Code Block sh
% codesign -d --entitlements :- path/to/myapp.app
Executable=/path/to/myapp.app/Contents/MacOS/myapp
<?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>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key> com.apple.security.device.usb</key>
	<true/>
</dict>
</plist>


The app has been built using PyInstaller and I'm manually signing it like this:
Code Block sh
codesign --entitlements entitlements.plist --options=runtime -f -vvv -s "Developer ID Application: *** (XXXXXXXXX)" /path/to/myapp.app/Contents/MacOS/Python
codesign --deep --entitlements entitlements.plist --options=runtime -f -vvv -s "Developer ID Application: *** (XXXXXXXXX)" /path/to/myapp.app


This was based on https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

I don't have an embedded provisioning profile as it's not mentioned in the above procedures. Do I need one? As far as I can tell I possibly need the sandbox capability because I'm using com.apple.security.device.usb but when I try to create a profile in "Certificates, Identifiers & Profiles" the sandbox capability is not in the list. Also, given that it's been working up until very recently I assume it's not required. Is that correct?
Posted by
glennra
Up vote reply of glennra Down vote reply of glennra
Add a Comment
I got it to work by removing the com.apple.security.device.usb key from entitlements.plist.
For some reason I thought that was required when using the hardened runtime, but apparently not.
Posted by
glennra
Up vote reply of glennra Down vote reply of glennra
Add a Comment

I don't have an embedded provisioning profile … Do I need one?

You only need an provisioning profile if you use constrained entitlements. Neither of the entitlements you’re signed with are so constrained.

I got it to work by removing the com.apple.security.device.usb key from entitlements.plist.

That is not a constrained entitlement.

It’s also unnecessary in this context because it’s only relevant for sandboxed app. Having said that, applying it shouldn’t break things.

Looking at the entitlement dump you posted it seems to have a space before com.apple.security.device.usb. That would definitely cause this problem, because one way that the system determines whether an entitlement is constrained or not is by looking for the com.apple.security., and a leading space would prevent that match.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment