Notarization is a big topic amongst Mac Admins, as we start to prepare to release macOS 10.15 Catalina to our fleets. Distributing tools, and allowing users to setup their own environments, is a huge part of the Mac Admin life. Today, Apple released some new guidance concerning the requirements for notarization of software packages.
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.Apple Developer News
Make sure to submit all versions of your software. While Xcode 10 or later is still required to submit, you don’t need to rebuild or re-sign your software before submission.
This represents a substantial change over the existing guidelines. This is a positive development, in my eyes, which allows more developers to submit their packages, disk images and zip files for notarization in their current form, and to work over a longer term to get the Hardened Runtime enabled, as well as find replacements for third-party pre-compiled frameworks that are submitted with another developer’s signature embedded.
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.
Cannonball 