我们有一个需要访问辅助功能API的Mac App Store应用。自10.9 Mavericks以来，有一个系统白名单用于想要使用辅助功能API的应用程序（系统偏好设置→安全和隐私→辅助功能）。
在测试我们的应用更新时，我们注意到从旧版本升级后，系统告诉我们，我们无权使用辅助功能API（AXIsProcessTrustedWithOptions返回{{1 }}），即使我们的应用程序位于白名单中，也选中了复选框。一旦我们取消选中并重新检查权限，一切正常。
显然，对于我们来说，这不是一个可接受的升级方案，尤其是因为可访问性白名单在系统偏好设置中被深埋，无法从代码中访问。
这是系统错误吗？有一个已知的解决方法吗？我们接受在重大更新后不得不重新检查辅助功能权限 - 只是将用户导航到系统偏好设置只是为了看到已经选中的复选框，而没有功能正常工作。
更新
在第一次升级后启动期间，系统会在控制台中抱怨：
NO奇怪的是，一旦未选中并重新检查辅助功能白名单上的权限复选框，即使二进制文件相同，控制台在后续启动期间也不会出现错误。
我已经窥探了实施访问白名单（16/03/15 06:47:10,343 tccd[190]: Unable to verify code signing identity of com.company.app: code failed to satisfy specified code requirement(s)
16/03/15 06:47:10,350 universalAccessAuthWarn[401]: AccessibilityAPI: pid 471, is not allowed to access the accessibility API. Path: /path/to/app
）的SQLite数据库。 /Library/Application Support/com.apple.TCC/TCC.db表包含一个access列，看起来像某个应用程序指纹/散列blob：
csreq（引用的哈希用“......”代替。）
现在，如果我安装旧版本的应用程序并运行它，系统会计算哈希并存储在$ sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select client, quote(csreq) from access'
com.apple.dt.Xcode|X'…'
com.apple.AccessibilityInspector|X'…'
com.ourcompany.app|X'…'
列中。如果我执行新应用程序版本的干净安装，我会得到一个不同的哈希值。
当我安装旧版本然后将其删除时，该列仍包含旧版本的哈希值。这可能是问题的根源吗？因为在更新应用程序之前将列设置为csreq时，一切正常。计算出新的哈希值，Accessibility API检查将返回NULL。
Same issue in a different app在GitHub上。
答案 0 :(得分：2)
有一个名为指定要求的东西（参见Code Signing Guide）。粗略地说，它是一组标准，系统使用它来确定两个应用程序包是否代表相同的应用程序，安全性方面。可以使用codesign -dvv --req - YourApp.app命令显示指定的要求。在我们的示例中，指定的需求检查失败，因为较旧的应用程序版本使用与开发版本不同的证书进行签名。
换句话说，当尝试使用开发版本替换Mac App Store版本时，由于证书不匹配而导致安全检查失败，您将不得不重新检查某些应用程序权限。据我所知，当你通过Mac App Store分发和安装相同的版本时，这不会发生。