As the dust settles on the recent Mojave 10.14.5 update, I’ve been looking at its undocumented change in the way that it handles kernel extensions. This article examines how this could trip you up, as it already has done for many users who tried to install Oracle’s VirtualBox 6.0.8.
At last year’s WWDC, almost exactly a year ago, Apple told developers that it was introducing a new system in which they could submit apps to Apple’s Notary Service, which would check and approve them, certifying them as ‘notarized’. For the time being, this was to be an option, but in a future release of macOS, it would become mandatory for all Mac software distributed over the Internet but outside the App Store. Everyone assumed that meant macOS 10.15, due to be detailed in a few days at this year’s WWDC, and expected to ship this autumn/fall.
Although notarization is free, take-up by developers seems to have been quite slow. Then early in the beta-releases of macOS 10.14.5, back in April, Apple suddenly warned developers that notarization would be compulsory in 10.14.5 for two classes of software:
- for all new and updated kernel extensions signed from 7 April;
- for all software signed by new developers, i.e. developers who hadn’t signed products before that same date.
When Apple released the 10.14.5 update, there was no mention of any of this in its release notes, nor can I find any advice it has provided to users about these changes. But the day after that update was released, Oracle released a new version of VirtualBox, its popular virtualisation environment. Those trying to install VirtualBox 6.0.8 quickly ran into trouble, reporting that it failed when the Mac had been updated to 10.14.5.
A workaround was quickly posted to user forums, to restart in Recovery mode and enter the following code in Terminal there:
spctl kext-consent add VB5E2TV963
The last group of characters is Oracle’s Developer ID.
Following restarting normally, most users found that VirtualBox 6.0.8 then installed correctly, and could be used.
My assumption was that the kernel extensions shipped in VirtualBox 6.0.8 had not been notarized, and it was the first casualty of this change in Mojave’s security policy. On closer investigation, though, it isn’t as simple as that. I have successfully installed VirtualBox 6.0.8 on macOS 10.14.5 without resorting to Recovery mode, but its kernel extensions don’t appear to have been notarized at all, despite being signed after Apple’s deadline.
This calls into question whether 10.14.5 does enforce notarization on new and updated kernel extensions at all. Perhaps Apple hasn’t informed us as this change has been delayed until 10.14.6 or even 10.15.
Examining the VirtualBox Installer package, it does contain kernel extensions which it requires in order to run. These are easy to find: when you first open the package in Installer, list its contents, and you should here see four.
Extracting one of them using Suspicious Package, it’s clear from the contents that there is no notarization ticket stapled to (inside) the .kext folder. Running the ultimate check of
xcrun stapler validate kextname.kext
confirms that they aren’t notarized, although each was signed on 13 May 2019, more than a month after Apple’s original deadline.
When I ran the Installer package here, on my iMac Pro and macOS 10.14.5, it failed the first time, generating the normal dialog which directed me to open the Security & Privacy pane to authorise installation of the extensions.
This I did, then ran the package again, which was successful in completing this time.
If you want to install a package which might contain kernel extensions in macOS 10.14.5, I recommend that you:
- Check at the start of the installation whether its list of contents does include kernel extensions.
- If it does, proceed with caution.
- If the installation fails or reports an error, look for the dialog inviting you to authorise installation of the kernel extensions, and use it to open the Security & Privacy pane. There, give approval for those extensions to be installed.
- After that, install the package a second time. If that’s successful, the job’s done.
- If that second installation fails too, discover the developer’s Developer ID, using WhatsYourSign or a similar utility.
- Restart in Recovery mode, and there substitute that ID in the Terminal command given above, to add KEXT consent.
- Finally restart in normal mode and install the package again.
- If you still can’t complete the installation correctly, contact the developer.
I hope that prevents you from suffering the problems experienced by those who updated to 10.14.5, then found that they couldn’t install the shiny new VirtualBox 6.0.8.