osx - AXIsProcessTrustedWithOptions returns NO even though the app is on the whitelist -

We have a Mac App Store app that needs access to Access-API. Since 10.9 Mavericks, there is a system whitelist for such an app that wants to use the Accessibility API (System Preferences → Security and Privacy → Accessibility).

While testing updates for our app, we have seen that immediately after upgrading from the old version, the system tells us that we have accessibility API ( AXIsProcessTrustedWithOptions returns NO ), even if our app is in the whitelist, with checkboxes checked Once we uncheck the permissions and check again, So everything works fine

Obviously, this is not an acceptable renewal situation for us, especially when the access whitelist is buried deep in the system preference and can not be used code.

Is this a system bug? Is there a known solution? We will accept the accessibility permissions again after a big update - it is unnecessary for your users to navigate system preferences only, to view the checkbox in advance without the feature.

Update:

---

During the first post upgrade launch, the system complains in the console:

  16/03/15 06: 47: 10,343 tccd [190]: Unable to verify code: Sign code of Com.company.app: Code fails to satisfy specified code requirements (s) 16/03/15 06: 47: 10,350 universalAccessAuthWarn [401] ]: Accessibility API: pid 471, Accessible API access is not allowed. The path: / path / to / app  

The strange thing is that, when accessed whitelist checkboxes are unchecked and re-tested, the console during subsequent launch There is no error in binary alike.

---

I have implemented the access whitelist ( / Library / Application Support / com.apple.TCC / TCC.db) in the SQLite database below white. ). There is a csreq column in the Access table that looks like a fingerprint / hash blob:

  $ sudo sqlite3 / library / application / support /com.apple.TCC/TCC.db 'Select the client, use the quote (csreq)' com.apple.dt.Xcode | X '...' com.apple.AccessibilityInspector | X '...' com.ourcompany.app | X <...  

(The hashs cited were replaced with "...")

Now, if I had an older version of my app Install and run it, then it is calculated by a hash system and stored in the csreq column if I have a clean install of the new app version, then I get a different hash .

When I install the old version and delete it, the column still hashes for the old version, can it be the source of this problem? Because when I set the column to NULL before updating the app, everything works fine, a new hash is counted, Accessibility API check returns such as YES That should be it.

---

On GitHub

Named Requirement (see) is one thing. Broadly, it is a set of criteria that the system uses to determine whether two app bundles represent the same app, security-wise designated requirement codesign -dvv --req - YourApp.app can be displayed using the command. In our case, the expected expected check failed, as compared to older App version development builds were signed using a different certificate.

In other words, when trying to create a Mac App Store with a development build, a security check will fail because the certificate does not match and you will have to re-examine some app permissions. As far as I know, it will not happen when you distribute and install the same build through the Mac App Store.