Notarization Requirements Relaxed

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.

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.

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.

[…] Notarization Requirements Relaxed […]

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.

A little bit late to the party… I'm trying to notarize (using Xcode 10 GUI) an application bundle consisting of more binary components and one of them (the application executable itself) is not build with support for hardened runtime. When I try to notarize the application, I still get an error that it isn't possible, because "MyApp.app must be rebuilt with support for the Hardened Runtime". What am I missing?

A little bit late to the party… I'm trying to notarize (using Xcode 10 GUI) an application bundle, containing more binary components, one of which (the application executable) is not build with support for hardened runtime. When I try to notarize, I still get the error that notarization is not possible because "MyApp.app must be rebuilt with support for the Hardened Runtime". What am I missing?

[…] Notarization Requirements Relaxed […]

OK, responding to my own questions, perhaps someone finds it useful… (and yes, I apologise for double post, for some reason I thought the initial attempt to post failed).

Apparently, Xcode checks locally if all binary components are build with hardened runtime enabled, without consulting Apple notarisation service and rejects to upload the archive if any component is not build that way. However, if I try the same thing using altool (which I'm actually doing in the automated build/notarize/upload/release script), the notarization succeeds, with one issue in the final report, with "severity=warning", and complaining about "executable does not have the hardened runtime enabled."

[…] * Notarization Requirements Relaxed (until January 2020) https://mjtsai.com/blog/2019/09/04/notariza… This explains why apps work at the moment (as of writing this)…Possibly in better terms than I could when I was arguing for this post. Requirements have been relaxed until January 2020. This post is also worth reading because there are some good perspectives here. …Not sure what else there is to say that hasn’t been said. Control like this is terrible for small developers. Switch to Windows. :( […]