4

Apple has announced that all programs in the next release of its operating system must be notarized.

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

How will this affect programs written in Python? Will they need to be notarized? Or will notarization be required for using certain APIs? How about browser plug-ins? Will they require notarization?

3

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:

Notarizing Your App Before Distribution

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.

Notarizing Your App Before Distribution

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.

MacOS Notarization

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

  • Thanks for the answer. Notarization will certainly create a problem for apps developed on computers that are not connected to the Internet. Will we be able to run our own executables without having them notarized, or will we need to have every test build uploaded to Apple? – vy32 Apr 17 at 22:28
  • @vy32 - This article seemed to indicate that "If the user is offline, Gatekeeper looks for the ticket that was stapled to the app." Guessing that the stapled ticket will be signed with some key that GateKeeper can verify even when offline. – slm Apr 17 at 23:35
  • That’s for people running apps offline, not developing offline... – vy32 Apr 19 at 2:34
  • @vy32 - sorry I didn't completely understand your Q in comment above. Doesn't appear you'll be able to sign an app if offline, will have to have Internet access. You can see this poor souls experience w/ doing the signing for a more detailed example - fdiv.net/2018/10/24/…. – slm Apr 19 at 2:40
  • 1
    Unfortunately there are many applications where a developer does not want to upload an app to Apple or is not able to do so for security reasons. Presumably there will be a way for developers to run their own app under a debugger without having it notarized? – vy32 Apr 19 at 17:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .