Greg said that the reason PDFpen crashed — even before it actually launched — was because Smile’s developer signing certificate from Apple had expired.
In the past, the expiration of a code signing certificate had no effect on already shipped software. PDFpen 6.3.2, which Smile still makes available for customers using OS X 10.7 Lion, 10.8 Mountain Lion, and 10.9 Mavericks, is signed with a certificate that expired long ago, and it has no trouble launching.
What’s new with PDFpen 8 is that, in addition to being code signed, it has a provisioning profile, which is essentially a permission slip from Apple that’s checked against an online database in order to allow the app to perform certain actions, called entitlements. For PDFpen, the entitlement that’s being granted is the capability to access iCloud despite being sold directly, rather than through the Mac App Store, a feature that wasn’t possible until about a year ago.
It sounds like every Developer ID app that uses iCloud has a built-in time bomb. Something is not designed properly here. First, why does Apple issue certificates with relatively short expiration dates? They already have a means of revoking certificates in the event of a problem. Second, why does the OS check whether the code signing certificate is valid now, as opposed to when the provisioning profile was signed?
Update (2017-02-22): Rick Fillion:
Due to the expired Provisioning Profile, 1Password mini wouldn’t launch. And without mini running, 1Password itself was unable to startup successfully. Both mini and 1Password itself were signed with the same Developer ID certificate. Gatekeeper allowed 1Password to run, but due to the different rules for apps with provisioning profiles, it would not allow mini to run.
As far as we can tell, the only way to correct this problem is to provide a new build of the app with an updated provisioning profile with a new expiration date.
When we generated our updated provisioning profile we also needed to generate a new Developer ID certificate. We didn’t realize it at the time, but the common name of newly created certificates now include the team identifier in addition to the company name; “Developer ID Application: AgileBits Inc. (2BUA8C4S2C)” vs. “Developer ID Application: AgileBits Inc.”. Close. Super close. But we weren’t looking for a “close” match.
In case you’re wondering how to tell when a provisioning profile will expire you can run
security cms -D -ion the Terminal to have it output information about a profile.
Update (2017-02-24): Rob Griffiths:
Follow me now, if you wish, for a somewhat deep dive into the world of code signing, as I attempt to explain—from a consumer’s perspective yet with a developer’s hat on—what is code signing, why these apps broke, why the breakage wasn’t expected, and other related questions and answers.
Follow me now, if you wish, for a somewhat deep dive into the world of code signing, as I attempt to explain—from a consumer’s perspective yet with a developer’s hat on—what is code signing, why these apps broke, why the breakage wasn’t expected, and other related questions and answers. Apple explicitly tells developers—in at least two places—that they only need these certificates to build new apps or update existing apps. So if you have a certificate that’s set to expire, but you don’t have an urgent need to update an app or create a new app, it’s supposed to be a non-event.
So the app can’t tell the user what’s going on, and even worse, the OS doesn’t tell the user what’s going on: The app just seemingly dies in an instant. That’s bad for the user, and bad for the developer, because they’re blamed for something they didn’t even know was occurring (because their app never loads, and no crash reports are generated). If the OS is going to kill the app, the OS should tell the user why it did so, so the user has some understanding about the problem.
Update (2017-03-09): Greg Scown:
Looks like Apple has addressed the Provisioning Profile issue.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.