From today, 3 February, Catalina 10.15.3 finally reaches what Apple had intended to be its launch point: all newly-built apps and command tools for Catalina are now required to be both hardened and properly notarized. This doesn’t mean that you can’t run apps or tools which aren’t, indeed you can still run completely unsigned apps if you wish. But if an app has been signed from today onwards and you expect it to pass Gatekeeper’s full first run checks, hardening and full notarization are no longer optional.

When Apple first announced this change at WWDC in early June 2018, it was anticipated that there’d be a period of a year or so during which developers ported their apps and workflows to incorporate these two requirements, so that when 10.15 was released in the autumn/fall of 2019, all new apps would comply.

I started setting the hardened option on my apps and submitted them to Apple’s Notary Service for malware checking in the summer of 2018, and by the time that Catalina was released last October they were all fully compliant. I’m fortunate in that most of my apps are, as apps go, relatively simple. They’re all developed in Xcode using Swift. Hardening is just a matter of opting in, and notarization generally takes a few extra minutes at the end of building for release.

Other developers had a much tougher job. Those using other SDKs had to develop their own scripts and tools to handle these requirements. In some cases, where a developer relies on external code such as libraries, there appeared to be insurmountable problems. I have five command tools among my free software, and although getting them notarized isn’t that hard, it took me a good while to work out just how to do it.

Apple recognised the problem with some legacy products, which couldn’t be retrospectively hardened or meet the other requirements for ‘new’ notarization, so allowed developers to submit existing products to its Notary Service for malware scanning and notarization.

Although that helped, it didn’t seem to be enough. Over the summer of 2019, it must have become clear to Apple that many important products weren’t going to make the deadline. On 3 September, it announced that, until January 2020, developers could get new versions notarized even though they weren’t hardened or fully compliant with the normal rules. Later, that deadline was moved to 3 February 2020 – the first day on which Apple applies its original strict rules for notarization.

What does all this mean for the user, though?

From today onwards, there’s only one class of notarized software. All new notarizations must follow strict rules, which require the hardened runtime to be enabled, every component properly signed with the developer’s certificate(s) and a secure timestamp, built using a recent version of the macOS SDK, and a few bits more besides.

There’s been a lot of debate about whether any of this really does improve macOS security, but little of that has been informed by any deep insight into how Catalina handles hardened apps, for instance. There’s always the claim that it’s all a waste of time, as it remains perfectly easy for malware to arrive without a quarantine flag, and skip all the important Gatekeeper security checks. If you really believe that is a sound argument, then you may as well skip most of the security built into macOS. But I think doing so would put users in a far worse position.

As things stand today, there are only three classes of (newly-built) software which will pass through Gatekeeper on their first run:

• software signed by Apple, such as the apps and tools bundled with macOS, and Safari;
• software delivered from the App Store;
• software supplied independently, which must be hardened and meet other requirements for signing, etc., and be notarized.

Until today, that has allowed developers to ship apps which contain executable code which is completely unsigned, for example. It is then easy for the app or malicious software to replace that code once the app has cleared its first run checks. Although there are flags which can be used to give apps leeway in hardening requirements, unsigned code is one reason for Apple’s Notary Service to refuse approval. Without being notarized, the app won’t then open normally on its first run, and you’ll be alerted to the problem. You can still choose to work around that and omit its full Gatekeeper checks, but that is your informed decision.

Improving security isn’t about certainties, it’s about risk. Each measure which Apple introduces to reduce the risk of the average, cautious user being successfully attacked by malware is a step in the right direction – so long as that measure doesn’t stand in the way of ‘good’ software and what we need to do with it. The malware scan performed by Apple’s Notary Service is hardly likely to detect every malicious app, but it’s almost certain to be better than no scan at all, so does reduce risk. The hardened runtime environment doesn’t prevent malware from running, nor from abusing ‘good’ software, but it almost certainly is better than no hardening at all, so it reduces risk.

I was an early adopter of hardening and notarization not because I felt that they were somehow good for my soul. The additional effort which they impose is, by and large, very small. If you report a bug, the longest delays in getting a fixed version out aren’t in hardening or notarization, but first in working out what and where the bug is, and then in arriving at a fix and testing it. Another few minutes to get the new version notarized is neither here nor there.

The return to you as a user is that you should have near-complete confidence that, when you first run an app downloaded from here, and it clears Gatekeeper’s checks, then it’s not malicious, because someone has subverted me or the servers which deliver my apps to you. You should have as much confidence in that protection as you would when downloading and installing a macOS software update, or an app from the App Store.

My heart goes out to those developers who, through no fault of their own, have found hardening and notarization an ordeal by fire. Hopefully, they have now recovered from their burns and had time to get their apps ready for today.

Over the coming weeks and months, we should finally start to see whether all this effort has been worth it, and does change the threat landscape in our favour.