Apple Should Provide Notarization for Open-Source Apps

As always, this post reflects my own opinions, and not anyone else’s.

With WWDC a month away, I’ve been thinking a lot about what I hope to see from Apple this year. Given the recent controversy surrounding notarization, it’s tempting to call for Apple to reconsider notarization. After all, notarization has been a huge pain for a lot of developers, myself included. But I don’t think it’s a good use of energy to dwell on things that are unlikely to happen. Instead, I’d like to propose a way that Apple could make notarization more of a positive for users. Apple could partner with open source hosting services to notarize open-source apps.

Ever since Apple introduced Gatekeeper, some high-quality open-source apps have been second-class citizens on macOS, their maintainers either unable or unwilling to pay Apple $99 a year for a Developer ID certificate. Many of these are niche apps, but there are notable popular exceptions, such as Audacity. Other apps, like Krita, have had trouble integrating notarization into their build systems, requiring manual notarization for every release.

At this time, most of the large, popular open-source apps are signed and notarized, a big improvement over where things were just a couple years ago. From that perspective, this may seem like a problem that will solve itself, but I’d like to explore why it may be in the best interests of the Mac platform and its users.

In the WWDC 2019 session Advances in macOS Security, Apple engineer Garett Jacobson laid out notarization’s place in their defense-in-depth strategy. Along with the hardened runtime, it helps ensure that unsigned code is not run by default. As Garett put it, “The security of the platform has become increasingly reliant on the validity of code signatures.” Implicit in notarization is Apple’s ability to pre-scan signed binaries for malicious code, and reading between the lines, we can assume that the price of acquiring code signing certificates from Apple is no longer prohibitive for large malware campaigns. It’s either cost-effective to purchase a new certificate when one is revoked, or malware authors have access to enough stolen certificates or credit cards that they can change certificates as required.

With the notarization requirement, Apple can block malware authors from distributing ready-to-run apps and installers no matter which certificate they use to sign them. Once the notarization service identifies malware, it can block that binary until malware authors alter it to the point where the service no longer recognizes it. If the binary contains a carefully-crafted exploit, in theory, the ability to modify it may be limited.

During the same WWDC session, Apple promised that there would always be a way to run Mac apps, even if they don’t meet Apple’s strict requirements. Up until now, it has been possible to bypass Gatekeeper by opening the app using a contextual menu instead of double-clicking it. I estimate that I have to do this about 50% of the time I download an app. This operation has become common enough that I have adjusted my habits to always open apps from a contextual menu after I download them, whether they meet Gatekeeper requirements or not. This completely bypasses the extra security measures Gatekeeper is supposed to provide.

Because the security of the platform has become increasingly reliant on the validity of code signatures, it’s in the best interests of the platform for as much software to be signed, notarized, and stapled as possible, even for advanced users. Even users who know how to bypass Gatekeeper responsibly can make mistakes, and they often provide tech support to family and friends who may not be knowledgable enough to distinguish safe software from unsafe software. If enough users get in the habit of opening apps using contextual menus the same way Windows Vista users got in the habit of always allowing access to UAC dialogs, it defeats a lot of the protection provided by the OS.

One way Apple could improve the availability of notarized software would be to partner with popular open-source hosting providers like GitHub, GitLab, and Bitbucket, as well as popular CI services for open-source software. Because the maintainers of many open-source apps lack access to a Mac, which is a requirement for signing and notarizing software, these services would need to have a way to acquire certificates from Apple, sign builds, and upload them to the notarization service.

As an aside, it would be wonderful if Apple could provide a similar service to their closed-source third-party developers as well. Since we have to upload apps for notarization anyway, it would be great if we could upload an unsigned binary and have Apple sign and notarize it for us. The code signing process is arcane, and it is not always obvious which actions are required to sign code for more complex projects. Between Mac and iOS apps, I have lost literal days to obscure code-signing issues. Multiplied across the millions of registered iOS and Mac developers, this would be a huge productivity win.

Even if limited to open-source apps, such a service could close the largest gap of unsigned apps. It would also deprive Apple of at least some revenue it currently gets from open-source apps. Some may be tempted to point out that Apple can certainly afford it, but Apple didn’t become the most valuable company in the world by passing up revenue opportunities. Yes, the developer program is less expensive than it was in the past, but the price drop allowed to Apple sell developer subscriptions to a much larger market, probably increasing revenue overall. Similarly, major macOS upgrades are now free, but this was done to make it easier for Apple to achieve internal goals. Increasing the amount of notarized software is a legitimate goal for Apple, but only Apple is in a position to determine if it’s worth the cost of developing this kind of service and forgoing some developer revenue.

But it is clearly worth it from my perspective, as it would signal that Apple still views the Mac as a viable platform for general computing and third-party apps. Although most companies would be thrilled to have a product that sells as well as the Mac, there is a lot of fear within the Mac developer community that management at Apple sees the Mac primarily as a means for their own ends. Specifically, that the Mac exists to develop iOS apps and sell Apple services.

This is not entirely unfounded. Over the last eight or so years, Apple has introduced features to the OS and then failed to improve them over time. App sandboxing is perhaps the highest-profile example. Many apps still can’t function in the sandbox without making use of “temporary” entitlements that have existed since 2012. Apple encourages us to file feedback asking for improvements to the sandbox, but crippling bugs, which have affected Apple’s own apps, remain, and as far as I am aware, only one entitlement has been added, not in response to any feedback. From the outside, it appears that Apple puts in just enough work on features to get them working for their own purposes and then performs the minimum required maintenance on them. Implicit in the current notarization controversy is the fear that Apple will not address these problems.

The rumored introduction of Xcode for iPad is the first step towards removing a lot of the Mac’s importance to Apple’s corporate goals. Investing money, time, and energy into improving notarization, at a real cost to Apple, would send a message to the community that Apple still sees value in the Mac beyond iOS and services.