Notarization Requirements Relaxed
As a reminder, Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. To make this transition easier and to protect users on macOS Catalina who continue to use older versions of software, we’ve adjusted the notarization prerequisites until January 2020.
You can now notarize Mac software that:
- Doesn’t have the Hardened Runtime capability enabled.
- Has components not signed with your Developer ID.
- Doesn’t include a secure timestamp with your code-signing signature.
- Was built with an older SDK.
- Includes the com.apple.security.get-task-allow entitlement with the value set to any variation of true.
This makes a lot of sense because the main benefit of notarization is the malware scan. It was never necessary to bundle that with all the other requirements.
It’s super important to check the logs because the warnings will become fatal errors again come January, 2020!
IMO, they have failed at both the end-user level and the developer level. This delay, while helpful, doesn’t address the core issues.
There is no easy way to tell if an app is notarized. End-users can’t tell which apps are or are not notarized.
I agree that there remain problems, but I don’t think this is something that end users need to be concerned with checking. Except for unusual ways of getting an app onto a Mac, and manually bypassing the launch check, the system is going to enforce that everything is notarized.
This does still mean you need to get notarized packages, zips and disk images for your environment if you intend to have 3rd party non-AppStorer software installed directly by end users. If you are installing tools via Munki’s LaunchDaemons or Jamf’s framework, this doesn’t apply yet.
Previously:
- Notarizing Command-Line Tools for macOS 10.15
- Security & Privacy in macOS 10.15 Beta
- The True and False Security Benefits of Mac App Notarization
- macOS 10.14.5 Requires New Developers to Notarize
Update (2019-09-06): Howard Oakley:
It’s also worth noting that some developers have reported that apps which have been successfully notarized don’t always complete Catalina’s first run Gatekeeper checks successfully, and as a result Catalina may refuse to open them.
Update (2019-09-09): Isaiah Carew:
relaxing the deadlines does not solve the terrible user experience issues.
nor the issue that you can’t staple a notarization receipt to a zip file.
even just in the public beta, the problems are already so numerous that i have a one-button form response to the issue.
As a user though I’m now left in doubt. Was all this performance with notarization and claims of its security benefits actually genuine? If so, why is this being postponed further, giving another three or more months of exploits? Or maybe Apple had overstated its benefits, in which case how is Catalina going to improve security, other than with its read-only system volume? If hardening and strict notarization do bring significant security benefits, why doesn’t macOS let me know which apps are well-prepared, and which are not?
Update (2019-09-10): Rosyna Keller:
Plugins are able to be stapled since Xcode 10.2.
See also: Howard Oakley.
Update (2020-02-04): Howard Oakley:
From today onwards, there’s only one class of notarized software. All new notarizations must follow strict rules, which require the hardened runtime to be enabled, every component properly signed with the developer’s certificate(s) and a secure timestamp, built using a recent version of the macOS SDK, and a few bits more besides.
Update (2020-02-24): Matt Deatherage:
It all seems like a standard (if accelerated) rollout of a critical security feature, and it was—with one exception. You may recall that Apple tied notarization to its Hardened Runtime environment, one that disallows several low-level features unless explicitly authorized by the developer in the code-signature.
Apple did not document the Hardened Runtime until WWDC 2019. Developers were asked to use a runtime environment that was not even explained to them.
Oh, sure, Apple made allowances for that. Until early 2019, developers could notarize absolutely anything, signed or not. Then there was a period where the Developer ID signing certificate did not have to match the certificate submitted with the notarization request. Both those periods ended in 2019 before Apple published Hardened Runtime documentation.
[…]
More resources on the Hardened Runtime might have fixed this, but one thing certainly would have. Hardened Runtime and notarization should never have been tied together. They are both security features that Apple wishes to require to protect its customers, but the binding of the two systems led to a 2019 full of “You have to notarize to launch on Catalina, but that means you have to use this other environment that we’re not really explaining yet.”
