Notarized software still gets labelled with `com.apple.quarantine` attribute

Question

DavidATX OP

Created May ’20

Replies 4

Boosts 0

Views 2.2k

Participants 4

)Hi All,

I'm a new developer taking over maintenance of a cross-platform application. I am trying to follow the notarization guidelines outlined here:

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

We have two versions of the software, one with bundled Python and another without. I am having issues with the Python bundled application. The one without Python bundle works just fine after notarization. The symptom of the bundled Python app is that even though all checks show the software is properly notarized and signed, when running it, I get the warning as if it has not been notarized at all! (" cannot be opened because the developer cannot be verified."

For the Python bundled version, I did the following:

- Sign all the binaries, .app bundle (via Developer ID cert)

- Sign all the Python binaries, dylib, Note, I did run into issues with the libraries not working after signing, so I added this entitlement when signing the Python binaries and DLLs: (via the same developer ID cert)

cat entitlements.plist
<?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>
<!-- These are required for binaries built by PyInstaller -->
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>

- Create dmg containing my own binaries and the Python distribution

- Sign dmg with same signing cert (Developer ID)

- Upload said dmg to Apple for notarization

- Upon receiving the successful notarization message, I stapled the notary receipt to the dmg for distribution.

After downloading the app from the internet, I manually verified that the notarization is still on the bundle and the dmg as follows:

spctl -a -t open --context context:primary-signature -v ~/Downloads/MyApp.dmg
/Users/blu/Downloads/MyApp.dmg: accepted
source=Notarized Developer ID

I also checked the .App bundle as well

spctl -vvv --assess --type exec MyApp.app
MyApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: XXXXXXXXXXX

However, when I open the .App, I get the standard message as if the software has never been notarized " cannot be opened because the developer cannot be verified."

If I check the xattribute of the .App bundle, I see the following:

xattr -l MyApp.app
com.apple.quarantine: 0181;5ebac12e;Chrome;8368045F-15F1-4EBE-BD54-D51FA4C43C8C

Does anyone know what I did wrong? Is it simply impossible to bundle Python with my application?

Boost

Answer 1

john daniel OP

May ’20

Bundling something like Python can be difficult. What error messages do you get in Console when you try to run the app after downloading?

0

Answer 2

DavidATX OP

May ’20

Hi John,

If i do it from the Terminal, I don't see any console output, just a popup that says ""APPNAME" cannot be opened because the developer cannot be verified."

Best,

David

0

Answer 3

Brigitte OP

May ’20

I don't think it is a problem about notarization, but about your Developer Certificate.

If an app isn't notarized properly, the message is somewhat about 'Isn't checked for malware'.

The message you see indicates what it said: Your Developer ID can't be verified.

If you want to distribute your app outside the Mac-Appstore you'll have to sign it with the Apple Development certificate, not with the Apple Distribution certificate. The Apple Distribution certificate is for distributing via Appstore.

And:

Nether sucessfull signing or notarisation will remove the quarantine-flag. The quarantine-flag tells macOS to check signing and notarisation.

Greetings

Brigitte

0

Answer 4

DTS Engineer OP

Apple

May ’20

I want to start by answering this:

Is it simply impossible to bundle Python with my application?

This is definitely possible to do, but it’s certainly not easy. Reviewing the details you posted, you’re actually doing better than most folks I’ve seen with problems like this (-: I do have some specific feedback…

You wrote:

I added this entitlement when signing the Python binaries and DLLs

You only need to add entitlements to executables. Adding them to non-executables can be actively harmful, so I recommend that you tweak your process to avoid that.

You wrote:

<!-- These are required for binaries built by PyInstaller -->

Do not put comments in your entitlements. Recent versions of macOS (and the notary service) have got snarky about this. If you do have comments, add a build step that strips them, as described in the Ensure Properly Formatted Entitlements section of Resolving Common Notarization Issues

com.apple.security.cs.allow-jit

…

com.apple.security.cs.allow-unsigned-executable-memory

Be careful with these entitlements. See this post for my general advice on that topic.

com.apple.security.cs.disable-library-validation

Are you planning to have your Python code load native code signed by other developers? If not, you definitely want to remove this entitlement. It’s presence causes Gatekeeper to be even more persnickety [1].

Oh, on this topic, make sure to test on 10.15.4 and later; it has an important bug fix in this space (r. 57278824). If you have to support older versions of 10.15.x, we can come back to that later.

On a more general front, I recommend that you read through Signing a Mac Product For Distribution. It has a bunch of info on how best to do this sort of manual signing. I also recommend that you read Testing a Notarised Product for info on how I test this stuff.

If you then still have problems, check out the advice in this post to see if you can find any clues as to what’s going wrong.

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

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

[1] Actually, it’s the reverse, in that library validation, which is what you get by default when you enable the hardened runtime, allows Gatekeeper to be a bit more relaxed because it can rely on library validation to defeat of whole class of attacks.

0