Gatekeeper rejects Non-sandboxed app with embedded command line tool

I have a Mac OS app that uses a separate swift-built binary to extend its functionality. It is non sandboxed and signed via Developer ID method.

I placed the binary file in Contents/MacOS directory of the bundle.

Here are the entitlements used to sign the bundle:

<!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.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
  </dict>
</plist>

When the application is built for arm64 (using arm64 built swift binary helper), successfully signed, notarized, and downloaded on a user's Mac, gatekeeper has no issues and throws no warnings.

When the application is built for x86_64 (using the x86_64 built swift binary OR universal swift built binary helper), successfully signed, notarized, and downloaded on a user's Mac, gatekeeper throws the "macOS cannot verify that this app is free from malware" warning.

So the issue seems to be the x86_64 swift built binary, but it is identical to arm64 build. I'm puzzled. Any suggestions on how to proceed?

Replies

Here are the entitlements used to sign the bundle:

Why are you signing with those entitlements? Specifically, com.apple.security.cs.disable-library-validation is only necessary if your app loads plug-ins from other third-party developers and, as noted in the docs, setting it can make it harder to pass Gatekeeper.

Share and Enjoy

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

Why are you signing with those entitlements? Specifically, com.apple.security.cs.disable-library-validation is only necessary if your app loads plug-ins from other third-party developers and, as noted in the docs, setting it can make it harder to pass Gatekeeper.

Removing that entitlement solved my issue. Thanks for the help.

It does make me wonder why gatekeeper behavior is different on M1 vs Intel though.

Removing that entitlement solved my issue.

Cool.

It does make me wonder why gatekeeper behavior is different on M1 vs Intel though.

Yeah, that is weird. Were you testing on a fresh machine in each case? This matters because Gatekeeper ends up caching a bunch of stuff in ways that are hard to purge. That’s why I test this stuff using the process described in Testing a Notarised Product (although I’ll admit that I don’t yet have this set up for Apple silicon).

Regardless, removing unnecessary hardened runtime exception entitlements is always a good thing.

Share and Enjoy

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

Yeah, that is weird. Were you testing on a fresh machine in each case?

Yes, pretty much as you described it in your guide. Mac OS 12.0 virtual machine on arm64. I would test both builds on the same VM, Intel through Rosetta, but yielding different results. Other users running Intel on bare metal reported the same issue on the same Intel build though.

Weird. If this were blocking your product I’d have you open DTS tech support incident so that I could look into it in more detail. However, given that your fix is the correct fix, I’m not going to recommend that. I’ll have to wait for the next developer to hit this |-:

mac OS 12.0 virtual machine on arm64.

What setup are you using for that?

Share and Enjoy

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

What setup are you using for that?

Macbook M1 Pro, macOS 12.0, Parallels 17.1.0

Add a Comment