Mac Code Signing at 20
This year marks the twentieth anniversary of Apple’s announcement of the introduction of code signing, although it wasn’t unleashed until Mac OS X 10.5 Leopard the following year (2007).
[…]
Apple had long maintained that users would remain able to run unsigned code in macOS, but that changed in November 2020 with the first Apple silicon models. Since then, all executable code run on those new Macs has to be signed. What hasn’t been mandatory is the use of a developer certificate for the signature.
[…]
Unlike some other operating systems, the only developer certificates recognised by macOS are those issued by Apple, but they’re provided free as one of the benefits of its $99 annual subscription to be a registered developer, as are unlimited notarisations.
Code signing makes a lot of sense in theory, but the developer experience still leaves a lot to be desired. It’s a constant source of annoying errors and failures, even when you aren’t changing things or doing anything non-standard. Last week, my apps stopped building because all the Developer ID certificates were expired. I have no idea why; I previously had a certificate installed that was good until June of this year.
Opening Keychain Access (which the alert at launch tries to discourage me from using) showed that that certificate was nowhere to be found. I used to keep a separate keychain file with just my developer certificates, but I’ve had to give up on that recently because Keychain Access will no longer copy items into it. It’s been unreliable at that sort of thing for years but now no longer seems to work at all.
The general rule with security certificates is that they’re only valid until their expiry date. When the certificate for a website expires, your browser should warn you if you try to connect to that site, and it will normally refuse to make the connection as a result. Thankfully, Apple’s signing certificates generally work differently.
When Apple adopted code signing using certificates that it issues, it recognised that applying that policy would result in apps having expiry dates enforced by their certificates, so applies a different rule. When a developer signs an app using their Developer ID Application certificate, a trusted timestamp is included to verify when that signing took place. Provided the certificate was valid at that time, and hasn’t been revoked since, the certificate is deemed valid by macOS.
Apple changed that several years ago, since when installer packages have normally been given trusted timestamps, so they now work the same as Developer ID Application certificates, and can still be run successfully after their certificate has expired, provided that it was valid at the time in their trusted timestamp, and hasn’t been revoked since. However, this has only recently been reflected in Apple’s guidance to developers, and is different from the account I gave here last week.
Previously:
- Logitech Certificate Expiration Breaks App
- Notarized Mac App That Downloads Malware
- Sequoia Removes Gatekeeper Contextual Menu Override
- Inside Code Signing: Certificates
- Inside Code Signing Technotes
- Gatekeeper Override for Indirect Launching
- Beware Apple Security Certificates After October 24
1 Comment RSS · Twitter · Mastodon
How many times was Xcode supposed to handle certs now?
Yearly ritual:
- Track down expired certs to delete in Keychain Access.
- Hit Renew in Xcode.
- Xcode fails to handle something, mandating Certificate Assistant voodoo from a guide and a manual upload to the developer site.
Apps for sale through Developer ID and the Crap Store still require annoying configuration that breaks Info.plist in Xcode, 15 years in.
Just codesign -vvv harder.
