How will Apple's Notarization impact programs written in Python?

Solution 1:

I'm starting to research this to better understand its implications as well, since I installed a number of 3rd party apps on my laptop and never use the store. Everything I install is either DMG or via brew.

Background & Python

For starters I would suspect any applications that are in binary form would be what Apple's referring to when they executables have to be notarized. A Python script, though executable, is not technically a binary, the shebang, #!/usr/bin/env python at the top is what makes it executable, so I would expect that only the literal /usr/bin/python binary would need to be notarized to appease GateKeeper.

APIs

If you look through the documentation around Notarization, you're uploading your build artifacts from your project to an Apple server where they'll analyze it and then provide a will return a unique ticket that you'll need to "staple" to your application. This ticket will allow GateKeeper to later verify your application for authenticity with Apple.

So they won't be doing anything through high level APIs, but rather through forcing applications to use macOS 10.9 libraries or later SDKS, per this bullet:

• Link against the macOS 10.9 or later SDK.

So they will be restricting applications through low level libraries (APIs) that they may be using.

Plugins

By default plugins will inherit whatever notary their native application they're running in will provide:

Plug-ins don’t declare their own entitlements. Instead, they inherit the entitlements of the host process. Therefore, a host app must include all the entitlements that prospective plug-ins require, even when the plug-ins are notarized separately.

However, this paragraph looks to state that basic plugins should be able to just work through their parent, but if they're doing something low level themselves, perhaps in some C plugin to Photoshop, this extra level of capabilities will need to be addressed by the parent app as part of its entitlement on behalf of the plugins that may run underneath the parent app.

For example, if a plug-in employs deep integration with the host executable via C function pointer overrides, or uses a JavaScript engine for custom workflows, the host executable must declare the Allow Unsigned Executable Memory Entitlement or Allow Execution of JIT-compiled Code Entitlement, respectively. In some cases, a plug-in fails to even load if the host executable lacks the proper entitlement.

An author's perspective

I found this blog post from the author of Acorn, a commercially available image editor.

And automating the notarization steps weren't as bad as I thought they would be. I wrote a Python script which calls out to the notarization tools with the addition of having the response format set to xml (and it was in the plist format, which was then easily fed into Foundation.NSDictionary). The script analyzed the current state of things and either waited a while before querying the notarization servers again to see if it's done, or stapled on the notarization bits if it was. Then a new build of Acorn makes its way to the internet.

Notarization adds a few minutes to the build time, but maybe it'll be worth it? I don't like having to depend on Apple's servers to put something up on mine. But if notariation prevents those "Foo.app is an app downloaded from the Internet. Are you sure you want to open it?" boxes from scaring customers unnecessarily, it will be worth the hassle. I can hope at any rate.

I felt like this author's perspective was reasonable. I've always just dismissed the warning when installing 3rd party software, but can understand some people's reluctance.

This article had some additional takes on Notarization that I found germane to you question but didn't want to overload my answer with too much more info. The article is titled: What the Apple Notarization Program for macOS Apps Means for You.

References

• Notarizing Your App Before Distribution
• How to notarize your software on macOS