Welcome to Part 3 in a three-part series of posts that go in-depth on recent events that caused macOS to prevent 1Password for Mac from launching on our customer’s machines. In this thrilling conclusion we’ll go into what we’ve learned and what the rest of the developer community needs to do to prevent this same sort of pain in their own apps.
In case you need to catch up on your reading:
We never take for granted that 1Password is an integral part of our customer’s workflows. It’s an app that has engendered a great deal of trust and any time we stumble and hurt our customers, we spend as much time as needed to fully understand what happened and make sure we cover our bases for the future. The events of this past week are no exception.
We’ve learned a fair amount over the last week, so let’s dive in.
Who This Affects
We went over this a bit in part 2, but we’ve been able to confirm that the issue we ran into is one that affects any Developer ID signed application also containing a Provisioning Profile. If your app has declared any codesign entitlements there’s a good chance you’ve got a provisioning profile. Often developers think of codesign entitlements only in the context of sandboxing an application, but they’re used for other things as well. In our case it is used to declare a keychain access group.
The presence of the provisioning profile will depend on your use of app services, which you can see in the Capabilities pane in the project editor when viewing the target in Xcode. If any of these options are set, there’s a relatively good chance that your app is shipping with a provisioning profile.
As a user, you can see if an app contains a provisioning profile by right clicking on the app in Finder, and choosing “Show Package Contents”. Then navigating to Contents to see if there’s a “embedded.provisionprofile” file. Seeing its expiration date requires that you open Terminal and use the
security cms -D -i command followed by the path to embedded.provisionprofile file. It will output the xml plist which will contain something that looks like this:
Generally, this provisioning profile is set to expire at the same time as your Developer ID certificate. One of the hallmarks of 1Password is that it tends to adopt the latest and greatest technologies that Apple has to offer right on day one. For this reason our provisioning profile was generated relatively early on and therefore we are one of the first ones to experience this pain.
We urge all developers that distribute an app outside of the Mac App Store to check whether their app ships with a provisioning profile, and to verify its expiration date.
Short Term Fix
When we generated our new provisioning profile last week we also created a new Developer ID certificate. Both this new certificate and the associated provisioning profile expire in 2022. In the short term this buys us a bit of time.
By the time you read this 1Password 6.6.1 will have been published on our website (with a major new version in the Mac App Store as well). This new version will help some users who have been having issues with the manual update process and also comes with a load of other goodies.
Longer Term Fix
Apple has posted a thread on their Developer Forum indicating they’ve made changes to the developer center to help with this problem. Newly generated Developer ID Provisioning Profiles are now valid for 18 years instead of 5. That takes us up to 2035, just in time for us to start worrying about y2k38 bugs. If our customers are still using 1Password 6.6.1 in 2035 then they’ve certainly missed a few update notifications. ?
Apple recommends developers generate new provisioning profiles to obtain one that has the longer expiration date. We’ll be doing this on our side shortly.
In practical terms, this solves the issue for our customers.
Proper Long Term Fix
Ideally there would be no expiration that affects users. A few years ago I resurrected a system from 1988 and set up an operating system from 1994 on it. Expiration dates on software would have made this impossible. It pains me to think of someone being unable to run 1Password in the future out of curiosity because of arbitrary limits such as this.
The issue we’ve filed with Apple
(rdar://30631939) regarding the inability to run apps with expired provisioning profiles remains open. We will continue to advocate for this to be changed and recommend that all developers of affected software do the same (please dupe the rdar). We’ll keep you updated if this changes.