How to handle notarizing apps and kexts that are generated programmatically?

My company has an automatic release process for our driver and associated apps. The driver is designed to work with an arbitrarily large number of different hardware configurations, and each time we make a release, our release process automatically does the following:


1. Generates a new Info.plist file for the kext containing the PID / VID combinations that the driver supports and then signs the kext using our "Mac Developer ID Application (With Kext)" certificate

2. Assembles together a combination of utility apps, launch daemons, and launch agents to bundle with the kext. Some of these apps may be modified during this process and then resigned using our "Mac Developer ID Application (With Kext)" certificate.

3. Builds a pkg containing the generated kext and apps and signs it using our "Mac Developer ID Installer" certificate

4. Assembles the pkg into a dmg


Some notes about this:


- Our kext is codeless, and its only purpose is to stop the default macOS HID drivers from taking control of the hardware devices we support.

- Our installers currently support macOS 10.7 and later, and it's important we continue supporting these early versions of macOS.

- The installer currently chooses which kext to install automatically at runtime, but other threads in this forum suggest that the installer will fail notarization if an unsigned kext is bundled into it, which concerns me.


At this point, I'm not sure how to integrate notarization into this process, and I have many questions.


Firstly, this process is not supposed to take longer than a few minutes. So if at all possible it's quite important that I avoid having to automatically send out each release we make for notarization. Is that possible?


Do we need to individually notarize each version of the kext? Meaning for every unique Info.plist we create, bundle into a kext and then sign, does that version of the kext have to be notarized? Or does it even need to be notarized at all since it's codeless?


What about the apps, launch daemons, and launch agents that are bundled into the installer? Do they need to be notarized? If so, how should we handle apps that are modified during the release process?


Lastly, does the installer itself need to be notarized? If so, will bundling unsigned kexts cause notarization to fail?


I'm worried that this notarization process is going to remove our ability to release software the way we need to, since we support a lot of different customers each with different versions of our apps and driver. Notarization seems to be intended for apps and kexts that are built and distributed in a more typical fashion. I would greatly appreciate any assistance that anyone can provide!

Replies

I can't comment on your Notarization and stapling issues. I haven't touched a PKG file in years and my life is much better for it.


However, I can tell you that Notarization is above and beyond any existing restrictions on kernel extensions. You would never even get an "Allow" button if your package wasn't properly notarized, at least on 10.14.5. At a fundamental level, you can't test anything about Notarization on 10.14.4. It doesn't take effect until 10.14.5.

Does that also apply to a flat PKG installer?

Yes. I’ve just created a new post, Notarising an Installer Package Containing a KEXT, that clarifies the relationship between KEXTs, installer packages, and notarisation.

Share and Enjoy

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

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