macOS 10.14.5 Requires New Developers to Notarize
Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.
In theory, this shouldn’t be a big deal. It’s like Gatekeeper, but signed by Apple. But, in practice, the notarization service sometimes goes down, or takes an unpredictably long time, or silently adds a requirement that wasn’t there the last time you deployed a build. So you never know how long it will take to get a bug fix out.
Via Rosyna Keller:
There’s also a new section about apps with plug-in SDKs and the hardened runtime.
Other sections of the Notarization docs were updated to address developer feedback.
Previously:
- Mac App Notarization and Customer Privacy
- Hardened Runtime and Sandboxing
- How App Launching Has Changed in Mojave
- Mojave’s New Security and Privacy Protections Face Usability Challenges
- AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms
- WWDC 2018 Links
See also: Howard Oakley, Jeff Johnson.
Update (2019-04-09): Rosyna Keller:
Resolving Common Notarization Issues has also been updated.
Additionally, it includes information regarding the fact devs with apps with plugin SDKs no longer have to separately ship a debuggable version and a notarized version.
TIL why I can no longer enter a fax number in the #macOS Print Dialog & therefore no longer use my Epson MFP to send faxes in #Mojave.
With 10.15 killing 32bit support, my ScanSnap’s software will stop working next.
I’ll soon need a VM to use my Mac for basic office tasks.
The reality now for Apple OS updates is that there’s no longer a distinction between major and minor updates.
All updates potentially include major new features. Or breakages.
Apple is now a full-on “Agile” shop, for better or worse.
(Narrator: For worse.)
Apple is getting aggressive with this stuff. Normally any Mac changes are years in the making.
This is awful. I really really hope they add an option to disable this just like SIP. I don’t really understand if this is possible.
Probably I need to move from macOS. Its a great OS but this kind of changes that could break anything...
who would want to develop on this platform or use this platform for IT professional services anymore. I’m 18 year veteran mac says admin/engineer and now considering switching to a linux machine to get my work done. apple have lost the plot.
My question here is: is it really that hard for a bad actor to pass the notarization checks that makes this worthwhile to impose on all other developers?
No, the whole thing is a complete joke, because apps can software update themselves outside the App Store and avoid Gatekeeper entirely. Submit a harmless version to Apple, notarize it, then flip the switch server-side to update to a new malware version after install.
[…]
The technical term would be “security theater”. :-)
John Daniel thinks it will still be effective against adware:
Because they would have to start writing code instead just running an automated app generation script. It is possible, but gets more and more difficult and costly.
About 28% of my users running my apps on macOS switched to the Windows version in the last 2 years. Apple now making it even more difficult for devs to create macOS apps will probably not improve this situation for them.
I haven’t worked on macOS for a year or two, but it seems like notarized apps are non-debuggable, and future versions will keep adding friction for non-notarized apps. Is it just me or is the Mac slowly losing its UNIX roots and leaning towards stripping users of control?
I haven’t seen any definition of “new developers” -- who fits into that? Does it mean developers that sign up for a developer app starting from today? And how is this enforced on the user’s computer? Or maybe this is enforced during the signing process? Seems weird.
My guess: info in the DeveloperID cert. It’s the only thing that makes sense at the OS level & explains why it applies “if you’re new to distributing macOS software, regardless of how long you’ve developed for other Apple platforms”. In other words, on generating new DevID cert.
See also: Hacker News and MacRumors.
Update (2019-04-10): Howard Oakley:
As ever, life isn’t quite as simple as Apple’s announcement might seem. It doesn’t, for example, address problems with command tools, which currently don’t pass through Gatekeeper checks, and are often unsigned, although it is possible to attach signatures to them. Apple still doesn’t have a scheme to provide an equivalent to notarization for command tools which aren’t embedded in an app or other code bundle. If you distribute your command tool as part of an Installer package, it is supposed to be possible to get the whole package notarized, although Apple hasn’t detailed a workflow for doing that, nor said whether all installer packages will be required to be notarized. Hopefully some time before 10.15 is released this will become clearer.
[…]
Notarization is only checked when you first run an app which has been downloaded from the Internet and has gained a quarantine flag as a result.
The requirement coming for non-App Store apps is notarization. You said its purpose is malware detection. That may be the purpose of uploading apps to Apple, but there’s more to it than that: you can’t notarize an app unless it’s hardened. So what’s the purpose of that?
There’s no good reason for the requirement. Notarization is a convenient excuse.
Apple is using the threat of Gatekeeper not allowing your app to launch in order force developers to do something Apple wants, self-impose the hardened runtime on your apps.
It’s a jerk move.
Kerio’s VPN Client was now dead in the water and not functional, no matter what I could do to follow up. An inspection (which requires Xcode 10.2 and not just the command line tools) of the kvnet.kext file in /Library/Extensions indicated I did not have a valid kernel extension any longer[…] Without a valid ticket stapled to the kext, I was going to have a problem running it, as the secureTimestamp value is after 2019-03-11.
Well crap. I need that kernel extension to work for my VPN to client locations to work, so how am I going to get around it? Thanks to #notarization on the Mac Admins Slack, and Allen Golbig at NASA Glenn, Graham Pugh, and the help of others, the answer was already in our hands: User-Accepted Mobile Device Management and Team ID Whitelisting in the Kernel Extensions Whitelisting payload in MDM.
Update (2019-04-11): Apple:
We’re working with developers to create a safer Mac user experience through a process where all software, whether distributed on the App Store or outside of it, is signed or notarized by Apple. With the public release of macOS 10.14.5, we require that all developers creating a Developer ID certificate for the first time notarize their apps, and that all new and updated kernel extensions be notarized as well. This will help give users more confidence that the software they download and run, no matter where they get it from, is not malware by showing a more streamlined Gatekeeper interface.
So if I understand these results:
- declare built with 10.14 SDK, hardening is required for notarization
- lie about that, or use older SDK, and you can notarize unhardened apps.
The part about “notarization will be required by default for all software” made me think, because there are a few apps that I’ve written over the years that are still useful (at least to me). All of them were built using Automator, which meant that the usual Xcode-based ways of notarizing applications wasn’t going to work for me.
Update (2019-04-12): Howard Oakley:
So if you’ve got folders full of your own apps which haven’t gained a quarantine flag because they weren’t downloaded from the Internet, or which have already cleared quarantine following download, they will continue to open and run fine in 10.15. Apple hasn’t announced that it’s changing the way that Gatekeeper works, and if it were even to consider that, the penalties would be seismic.
That does, though, leave many wondering how they’re going to be able to share tools as they have in the past. Unfortunately, the news for them isn’t good at all. If you want to make such apps available to others via download, the only way that this will work in 10.15 and later is for you to go through the whole process of signing them with a developer ID and notarization. Probably.
[…]
How on earth can an app be hardened, something only available in recent versions of Xcode, to meet the first requirement, but remain unsigned?
The answer seems to rest in what built the app in the first place. If the app declares that it was built using a recent version of Xcode, which supports hardening and notarization, then the latter will expect it to comply with the new and rigorous rules, including code-signing and hardening. If your app is built with an older version of Xcode, or a different tool, then legacy rules apply, as described later in that article.
We use Packages for easily creating distribution packages, and DropDMG for making great looking disk images. The notarization process involves uploading a copy of the app to the notarization service at Apple, then polling the service until it is complete, then downloading the ticket and “stapling” it to the app. So our new process looks like this:
Archive Build->Upload->Poll Until Success->Staple->Package->Add to DMG
Update (2019-04-22): Howard Oakley:
Typical notarizations take less than 5 minutes, from completing upload to Apple’s server to the app being ready to distribute. It’s been unusual for any to take much longer than that, although there were a couple of occasions last October which were delayed by over an hour. I’ve not had any failures at all, neither have I discovered the service to be unavailable. Generally speaking, I can get an app from final test build to distribution on this server within 10-15 minutes when I need.
Twice, just recently, Xcode 10.2 has reported silly errors as if I wasn’t notarizing but trying to send for review for the App Store. I simply quit Xcode, opened it again, and notarization worked fine.
Undoubtedly your experience will vary, as will mine now that the Notary Service is becoming more heavily used.
So, if you deliver an unstapled object, as DisplayLink has, it may still pass muster, but that requires your machine to be able to talk with Apple at the time of install. If you are operating a network which embraces 802.1X user certificates, and you install software at the login window (with Munki, say) you may run into a circumstance where the software is actually notarized by Apple, but without that stapled ticket, you’re stuck if you can’t talk to Apple to prove it. This will result in a failed install.
Update (2019-04-23): Adam Maxwell:
We had an argument over this on the MacTeX mailing list. The concern is that self-signed software like TeX Live Utility and BibDesk can’t be shipped with MacTeX anymore. I won’t install Mojave, and no way am I paying Apple $100/yr for the privilege of writing free software.
Update (2019-05-09): Mark Munz:
I don’t understand why @Apple
1) Pushes devs to get apps notarized.
2) Makes that work virtually invisible to user.w/o digging into Package contents, doesn’t seem to be a way for users to look at app & know whether or not it is notarized.
Update (2019-05-23): Rosyna Keller:
FWIW, if your software meets the “requires notarization” criteria on macOS 10.14.5 but isn’t notarized, the user will see a dialog similar to this.
Update (2019-05-30): Howard Oakley:
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.
[…]
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 VB5E2TV963The last group of characters is Oracle’s Developer ID.
And since then it looks like Oracle has notarized the extension, so it works even though it isn’t stapled.
Update (2019-06-14): Matt:
I can’t notarize anything due to this error, and Apple support has been no help.
Update (2019-06-17): Rosyna Keller:
Starting in macOS 10.14.6 beta 2, Mojave will now load tickets stapled to installer packages even if they aren’t quarantined to aid in automated installs of kexts.
Update (2019-07-23): Rosyna Keller:
If the disk image is signed, it needs to be notarized (this is true on 10.14.5+ too for signing certs issued after April 7th). Unsigned disk images subject to translocation don’t need to be notarized.
In summary: to avoid Gatekeeper Path Randomization you need to code sign your disk image, and if you do that then notarizing the app on the disk image via Xcode is not enough. You need to use the custom notarization workflow, i.e. altool, to notarize the disk image, too.
This is shit.
