Wednesday, September 4, 2019 [Tweets] [Favorites]

Notarization Requirements Relaxed

Apple:

As a reminder, Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. 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.

This makes a lot of sense because the main benefit of notarization is the malware scan. It was never necessary to bundle that with all the other requirements.

Rosyna Keller:

It’s super important to check the logs because the warnings will become fatal errors again come January, 2020!

Mark Munz:

IMO, they have failed at both the end-user level and the developer level. This delay, while helpful, doesn’t address the core issues.

There is no easy way to tell if an app is notarized. End-users can’t tell which apps are or are not notarized.

I agree that there remain problems, but I don’t think this is something that end users need to be concerned with checking. Except for unusual ways of getting an app onto a Mac, and manually bypassing the launch check, the system is going to enforce that everything is notarized.

Tom Bridge:

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.

Previously:

Update (2019-09-06): Howard Oakley:

It’s also worth noting that some developers have reported that apps which have been successfully notarized don’t always complete Catalina’s first run Gatekeeper checks successfully, and as a result Catalina may refuse to open them.

Update (2019-09-09): Isaiah Carew:

relaxing the deadlines does not solve the terrible user experience issues.

nor the issue that you can’t staple a notarization receipt to a zip file.

even just in the public beta, the problems are already so numerous that i have a one-button form response to the issue.

Howard Oakley:

As a user though I’m now left in doubt. Was all this performance with notarization and claims of its security benefits actually genuine? If so, why is this being postponed further, giving another three or more months of exploits? Or maybe Apple had overstated its benefits, in which case how is Catalina going to improve security, other than with its read-only system volume? If hardening and strict notarization do bring significant security benefits, why doesn’t macOS let me know which apps are well-prepared, and which are not?

Update (2019-09-10): Rosyna Keller:

Plugins are able to be stapled since Xcode 10.2.

See also: Howard Oakley.

21 Comments

My prediction is that as soon as they require it users with older no longer supported software will be up in arms. The 64 bit change is bad enough. To make even 64 bit software people paid good money for stop working will anger a lot of people. Munz point that, unlike 32 bit software, there's no way to even know what software will work is pertinent. Apple gave a lot of time to get ready for 64 bit with warnings. There's no warnings about notorization.

My guess is come January they still won't do this.

Sören Nils Kuklau

The 64 bit change is bad enough. To make even 64 bit software people paid good money for stop working will anger a lot of people.

But how many apps will there be that people recently have paid for, and are 64-bit, and yet haven’t received an update to be notarized by January?

@Clark Does it matter that much to end users who already have the apps installed? My understanding is that the notarization check is only at first launch because after that the app is no longer quarantined. So nothing should stop working (except 32-bit stuff).

"This does still mean you need to get notarized packages, zips and disk images"

- You can _not_ notarize zip archives.

- AFAI, notarizing disk images is painful and a terrible non-optimized workflow as you can't notarize a read-write disk image and then convert it to a read-only/compressed disk image without losing the stapled tickets.

If you add to this all the design issues with notarization and stapling tickets, the confusing e-mails you get when the notarization failed, it's reasonable to say that Apple is not ready for notarization, from a toolchain point of view.

@Michael It's unclear whether notarization check is only performed at first launch. In some documents, WWDC sessions, Apple mentions that the checks are also performed on a regular basis. It's also unclear whether this corresponds to the quarantine flag being put back by some Mac App Store apps or not (also, in the WWDC 2019 session, it was stated that Gatekeeper behavior will change in macOS 10.15 and the apps will be scanned even when the quarantine flag is not set). Nothing is crystal clear with Apple these days.

“End-users can’t tell which apps are or are not notarized.”

Users should not need to know this. Users do not want to know this. All users want to know is that they’re safe. Developers who do not start at that user requirement and work backwards to the “How do we implement it?” from there can only add to the problem, not solve it.

The modern desktop is an inherently insecure, unsafe environment. Apple may be making many mistakes as it tries to retrofit user security onto that, but at least they’re making them. The peanut gallery not only doesn’t understand the problem space, it doesn’t even understand that it doesn’t understand it.

@stephane I presume Tom is referring to ZIP archives containing notarized apps. My recollection of that WWDC session is that non-quarantined software will get a malicious content scan in Catalina, but I think that’s separate from the notarization check.

"Users should not need to know this. Users do not want to know this."

Users *should not* need to know if their apps are 32-bit or 64-bit, should not need to know if they are PPC or Intel, or any of the other transitional changes over the years. Yes, those are all implementation details, but any production office is going to what to verify that all their required apps are ready to go before upgrading their OS. Apple has a (poor, IMHO) approach for this for 32-bit apps, but absolutely no (easy) way to know if the app is notarized.

Even from a testing stand point, as a developer, I can't look at an app to know if it is successfully notarized or not. I have to go to the command line to find out. Let's be honest, having a visual marker would've give developers a stronger incentive to jump thru Apple's hoops earlier. We could then market that support to users, just like we did for 64-bit apps, Intel support, etc. Notarization is invisible to the user. It's just more work for the developer w/ zero visible benefits. I believe that is one of the reasons (but not the only) that developers haven't jumped on board like Apple wanted. The other one is that they made the process more complicated than it needs to be for the developer themselves. So invisible AND requires a lot of additional work to implement in your workflow. And if you're automating, there is no good documentation, so you are operating in the dark. Is it any wonder folks have dragged their feet? IMHO - Had Apple addressed EITHER one of these issues last year, they probably wouldn't have to delay their notarization requirements right before Catalina ships.

I'm speaking from experience here. Supporting Hardened Runtime – super easy. Flip a switch. Do some testing. Manually integrating a new asynchronous task into the existing build process – harder. I got some of the automation wrong and got locked out my account. I keep working with an undocumented responses and just have to hope the values I expect are right. That's all time taken away from actual work on my app's functionality. Now, I assume there are a lot of developers that had to do similar.

Now consider the alternative, a checkbox in a scheme's archive options. [ ] Notarize app. So the asynchronous build is extended to include notarization. And if you're using the command line, add a notarize command, so "build archive notarize". Now you can export the notarized app and you're good to go. That change in my workflow would take me no time to make.

"My understanding is that the notarization check is only at first launch because after that the app is no longer quarantined."

https://developer.apple.com/videos/play/wwdc2019/701/ - all new software requires notarization, that includes any builds after June 1, 2019. So basically, any app updates will have to be notarized. The only time it won't matter to the user is if they don't ever update their software.

"is that non-quarantined software will get a malicious content scan in Catalina, but I think that’s separate from the notarization check."

According to same WWDC info, that is correct. All apps get a malicious check, notarization is only for quarantined apps. For now. I wouldn't be surprised if Apple doesn't expand that to each launch by 10.16.

@Mark It’s like Gatekeeper in that the user only sees a visual difference when the installing. The dialog that you get even on 10.14 if the app isn’t notarized is rather scary and borderline FUD, in my opinion. So I think that’s a pretty strong incentive. It would be interesting to compare the uptake of Notarization vs. the original Gatekeeper. My guess is that despite less of a carrot and less of a stick, Gatekeeper had faster adoption because it was easier to add to your workflow. Also, notarization feels like it offers diminishing returns: macOS is already scanning for malware, and the app is already signed with a certificate that Apple could revoke, so what is this extra step really gaining me?

@Michael

You're probably right but, from a performance point of view, it might be faster to first check whether the app is notarized (and a ticket has been stapled) and what the timestamp of the notarization is.

If the app is notarized and the timestamp is more recent than the XProtect signatures date (which can be the vast majority of cases considering how often Xprotect has been updated so far), then it's not necessary to scan the app.

"Also, notarization feels like it offers diminishing returns: macOS is already scanning for malware, and the app is already signed with a certificate that Apple could revoke, so what is this extra step really gaining me?"

One of the supposed benefits is that you can revoke a specific build of an application because there is a timestamp. But it was already possible to codesign with a timestamp previously. Surprisingly Apple decided to turn off the timestamp option by default when not archiving. I always thought it was on by default before reading about this while looking for notarization info. So if you were using xcodebuild from a build script, your apps would not be signed with a secure timestamp even with the Release configuration.

I don't understand this remark on the Tom Bridge blog post:

"find replacements for third-party pre-compiled frameworks that are submitted with another developer’s signature embedded"

Can't you just resign the framework with your own Developer ID cert? You don't have to have the source to do that.

@aaron Yes, I think you’re right.

Apple's post says: "You can now notarize Mac software..." But you can only notarize *apps*. Other software that Gatekeeper is checking and flagging as not-notarized ("Damaged, throw in the trash") just can't be notarized -- Apple's process simply doesn't support it. The left hand doesn't seem to know what the right hand is doing.

Damiano Galassi

You can notarise frameworks, dylibs, cli apps too. Everything that can be run. Which are the "Other software that Gatekeeper is checking" that can't be notarised?

@Damiano dylibs and CLI tools can not be fully notarized. You can not staple a ticket to a standalone binary.

Per the documentation "Although tickets are created for standalone binaries, it’s not currently possible to staple tickets to them."

There's confusion between notarization and stapling a ticket to your software. The latter is not required.
Command line tools can be notarized - I have notarized five now, and detail the process on my blog. However, Apple still hasn't worked out how to staple the ticket to a single-file tool. In this context, it doesn't matter - those tools are now notarized, and satisfy Catalina's requirements.

@E Howard N Oakley

"In this context, it doesn't matter - those tools are now notarized, and satisfy Catalina's requirements."

If you launch them for the first time without an Internet connection, you may not enjoy the result. Idem for a kernel extension that would try to be loaded before the Internet connection is established (or if the connections to the Apple servers are denied).

[…] Notarization Requirements Relaxed – Michael Tsai […]

@ Damiano AppleScript script libraries containing frameworks. They can't be notarized, and Gatekeeper refuses to load them because of it.

When I started studying comp sci in 2000, I was one of the first people who had a Mac. By the end, in 2005, about half the people in my class had Macs, because they were just so damn convenient. By then, I think Tiger had come out, which was a really good operating system, and it allowed you to easily run Microsoft apps and Adobe apps and Java and Unix stuff on the same device. Comp sci students loved it because it did all of the things they needed in a pretty, user-friendly interface, and on some of the best hardware available.

A lot of good came out of that. At the time, I worked on a de-novo genome sequencing application, and as a side-effect of the popularity of Macs, it just also worked on Macs. A lot of applications, particularly a lot of niche applications, that were previously Unix-only or Windows-only were now available on Macs.

What Apple is doing now is making Macs less and less convenient for developers, and, in addition to just being shitty for all of us, this will have repercussions for software availability.

> Comp sci students loved it because it did all of the things they needed in a pretty, user-friendly interface, and on some of the best hardware available.

This was the exact conversation I had with a computer science professor at my college in 2007. She could run Mac OS X, Windows, & Linux on it, and the hardware + interface were great, so it was an easy decision for her. In addition to being nice-looking hardware, it also had a degree of pragmatism that made it attractive to devs.

I agree that all these new policies and restrictions are culminating in Apple not only isolating themselves from the rest of the computer industry, but also making it harder for those who remain to publish software for their computers.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment