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.

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:

<key>ExpirationDate</key><date>2022-02-17T23:59:55Z</date>

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.

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.

What is the last version of 1PW before you started adding the provision profile, version 6.3.2? (Starting with 6.3.3, they are pkg files instead of zip).
I don’t like that I cannot install any version of 1PW at any time in the future on an older machine if I wanted to. For me, 1PW seems to be the only piece of software using a provision profile that I can tell.

I know for sure that 6.5.1 and later contain an embedded provisioning profile that was affected by this issue. XCode automatically embeds a provisioning profile sometimes so I wouldn’t be surprised if earlier versions had it as well. I’m not at my test machine so I can’t scratch my curiosity itch at the moment – if you’re in a good position to test I’d love to know ?

Regardless I don’t think this is a good long term solution. I really hope radar 30631939 gets some traction so nobody needs to worry about this.

By the way, many apps have a provisioning profile and aren’t affected by it’s expiry date. I’m not sure why. It appears you need to set things up just right to tickle this bug.