This summer, I gave a talk at the Mac Admins Conference at Penn State, focused on Notarization, called The Loyal Order of Notaries. It was a lot of work to put together the talk, and I spent more time on it than I have any talk I’ve ever given. I am proud of the work, but there’s a problem.

I Got Something Very Wrong

46 minutes into the talk I said: “this is good news: whitelisting the Team ID affects the notarization restriction.”

This is not correct.

Whitelisting the Team ID in a Kernel Extensions payload from a User-Accepted MDM does not affect the notarization requirements in the Catalina betas at this time. What I said in the talk was based on my conversations with colleagues and friends, and an conversation I’d had with a member of Apple’s staff, and on my initial results with the first beta of Catalina.

My conclusions were based on the question I asked in that inteview: Will there be a way to whitelist Developer IDs for notarization the same way there is for Kernel Extension loading? The answer was an unequivocal yes.

I assumed that the method for this was the same payload. That has turned out not to be the case in my testing thus far.

So What Now?

I don’t know.

That’s not a very satisfying answer, I recognize. I wish I had a better one.

Here’s what I do know: merely providing a kernel extensions whitelisting of the Team ID of a Developer is insufficient to prevent warnings for packages and disk images signed with that Developer Certificate.

I feel like I blew it.

I had tested this with my Catalina machine, but I realized that the package I was testing with was signed, and with a Developer ID I’d whitelisted, but it wasn’t a unique path or package. I had already installed that package once before, before I’d whitelisted the Developer ID. The LaunchServices Database had a record of the package and the path from where it had come from. It had already exited quarantine, and thus wasn’t passing through the Gatekeeper checks that the talk described, despite having been uninstalled.

How Do I Deal With Non-Notarized Materials?

Catalina’s requirements for notarization on signed packages, signed disk images and unsigned zip files are enforced by Gatekeeper processes, which depend on file quarantine flags. If a package, disk image or zip file arrives via browser download, USB file transfer, or AirDrop transaction, it comes with a quarantine flag. Escaping quarantine means passing a notarization check (online or offline), and a code-signing check, and a check for malicious code as defined by MRT and XProtect.

Or, you can deliver the payload through a non-quarantine method, like curl, or the jamf binary.

These methods are not quarantine aware, and while they do carry some additional ACLs, they do not appear to prevent the installation of packages by Apple-signed Installer, or mount of the image by Apple-signed Disk Utility. That means that tools like Munki or Jamf can continue to deploy software that is not notarized to enterprise machines.

One other consequence of these changes is that it’s not just packages software programs that are affected. During testing, I found a package that is properly signed that delivers Motion and Final Cut Pro templates that also triggered the quarantine warning. They were signed for distribution, but not notarized. They still flagged the quarantine check because they were distributing files. I packaged a sent of fonts for delivery to /Library/Fonts, signed the package, uploaded it to Slack for a colleague to test, and sure enough, quarantined:

If you’re planning for your co-workers to be able to open packages, zip files or disk images that aren’t notarized, you’re going to need to prepare them to right-click on the file, click Open, and then accept the warning that follows.

This isn’t ideal.

This will mean that anything you intend to deliver to Catalina computers will need to either arrive without a Quarantine flag, or be installed by a tool that can receive updates without a Quarantine flag and install them directly.

I apologize to the folks in the room at Penn State, to the organizers of the Mac Admins conference, and to anybody who will see the video. I got it wrong. But I’ll own what’s mine, and we’ll learn more together in the future.