macOS 10.15.4: The signature could not be validated because AMFI could not load its entitlements for validation

Since updating to macOS 10.15.4 I am no longer able to launch applications.

Applications in general? Or an application you’re building?

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

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

We're having the same problem, with seemingly no sollution.

We're trying to codesign an app for MacOS made with Unity, we follow the following guide to do so:
https://docs.unity3d.com/Manual/HOWTO-PortToAppleMacStore.html

But as soon as we codesign the .app file, we get the same error message in our system.log

"The signature could not be validated because AMFI could not load its entitlements for validation: entitlements cannot be parsed"

The .app works fine before codesigning, you'll have to circumvent Apple's gatekeeper but it launces.
After codesigning it just completely fails to start.

Ah, sorry I wasn't clear on that. An application I'm building.

Some more relevant information, this is checking the entitlements file:

$ plutil -lint ./entitlements-app.plist
entitlements-app.plist: OK

And this is checking the entitlements of the signed application:

$ codesign -d --entitlements :- X.app           
Executable=X.app/Contents/MacOS/JavaAppLauncher
<?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.app-sandbox</key>
        <true />
        <key>com.apple.security.network.client</key>
        <true />
        <key>com.apple.security.files.user-selected.read-write</key>
        <true />
    </dict>
</plist>

And finally, checking the signature of the application:

$ codesign -dv --verbose=4 X.app
Executable=X.app/Contents/MacOS/JavaAppLauncher
Identifier=nl.colorize.X
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=629 flags=0x0(none) hashes=12+5 location=embedded
VersionPlatform=1
VersionMin=657152
VersionSDK=659200
Hash type=sha256 size=32
CandidateCDHash sha1=3391bd8553b19504509e9efe3a2db9c58db0826b
CandidateCDHashFull sha1=3391bd8553b19504509e9efe3a2db9c58db0826b
CandidateCDHash sha256=18b8be64f3e7645f0dc76c4b75d5c5864309f930
CandidateCDHashFull sha256=18b8be64f3e7645f0dc76c4b75d5c5864309f9305c48c2ddd2307038c8a1642f
Hash choices=sha1,sha256
CMSDigest=2a1827e28605d4c92c6d08aab140eeef06720784690193340fd67eec80c99ced
CMSDigestType=2
Page size=4096
CDHash=18b8be64f3e7645f0dc76c4b75d5c5864309f930
Signature size=4806
Authority=3rd Party Mac Developer Application: X
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=9 Jun 2020 at 21:07:22
Info.plist entries=24
TeamIdentifier=F9TKFY3EK3
Sealed Resources version=2 rules=13 files=72
Internal requirements count=1 size=200

Seems like none of these checks indicate an obvious error. And again, I have distributed my application with the same entitlements several times, until I started to get this error after updating to 10.15.4.

@simulationcrew We are not using Unity, but we are using Java. That means both of us are embedding frameworks in the Contents/PlugIns directory within the application bundle, so my guess would be that the error is somehow related to the usage of such frameworks. However, the error message is not very helpful in understanding what's wrong.

10.15.4 fixed a security vulnerability by enforcing much strict entitlement parsing. This isn’t a problem for most developers because Xcode does the right thing. However, I’ve seen a number of folks like yourselves, using third-party tools, run into a problems because of oddities in their entitlement formatting.

Try this:

% codesign -d --entitlements tmp.plist X.app
% plutil -lint tmp.plist
% xxd tmp.plist

You’ll most likely see that your entitlements have one of following problems:

• Some subtle structural issue

• It’s a binary property list, not XML

• A leading byte order mark

• A weird-o text encoding

• Non-standard line endings (you need to use UNIX-style LF, not CR LF, or CR)

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

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

Thanks a lot for that suggestion Eskimo! When I try these steps I get the error message "temp.plist: Unexpected character ú at line 1". Based on your list this is most probably an issue with the UTF-8 BOM in the file. Interestingly, the original entitlements file does not have a BOM, but this is probably added somewhere in the build process. I'll investigate, but this helps a lot.

Probably good to add the conclusion in case other people stumble upon this post. The problem was that codesign is *very* picky about the entitlements XML file. In my case, I removed all redundant whitespace and the problem went anyway. When I mean remove redundant whitespace, I really do mean all of it. So I needed to change "<true />" to "<true/>" (i.e. without the space), otherwise I get the error.

Note that the extra whitespace is perfectly legal in XML, which is probably why none of the tools was able to find the cause. I have no idea why the XML validation is so strict and haven't seen anything like it, but at least this solves it.

I have no idea why the XML validation

That’s because of the security vulnerability I mentioned above.

My recommendations for building your entitlements:

• Use Apple tools, which will automatically format things correctly.

• If you’re manipulating the XML with non-Apple tools, use the -convert option to plutil as a final tidy up, as described in the Ensure Properly Formatted Entitlements section of Resolving Common Notarization Issues.

Share and Enjoy
—
Quinn “The Eskimo!” @ DTS @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 22 Jun through to Fri, 26 Jun. During that time all of DTS will be busy with conference duties.

Hello. I am running into some similar issue, while trying to launch a Python 3.8 application of my own from crontab. The app crashes and the message I see in the console is this:

20:51:17.666670-0500.   Kernel    AMFI: Process does not have a code signature, allowing core dump for pid 14053

The App is launching several processes using the 'fork' method, and the crash takes place when a new Process is launched as a daemon to execute a query on a URL in internet. Any help will be very appreciated. After several days trying to make this work, it keeps failing consistently. The behavior remains after changing the method to generate a new Process from 'fork' to 'spawn'. Thank you very much in advance.

I am running into some similar issue, while trying to launch a Python 3.8 application of my own from crontab.

I recommend that you start a new thread for this. While the symptoms are similar, the details will be very different.

Please use the same tags so that I see it go by.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"