Mac应用程序的数字签名被破坏时，可能会引起什么烦恼或真正的问题？
Mac上的应用程序可以进行数字签名。当签名以某种方式被破坏时，我知道一些应用程序可能会注意到这一点。但是我不知道这些只是烦恼或会破坏事物的细节：
OS X防火墙可能无法正确设置临时签名，导致反复提示“您是否希望应用程序'[..]'接受传入的网络连接？”
家长控制所允许的应用程序可能不再运行？
钥匙串访问可能已损坏？
有人说Apple软件更新可能会失败。如果为true，那么我想知道这是否确实取决于代码签名签名，或者是否由整个应用程序的某些不匹配的哈希值或BOM表文件中的信息引起。
以下是更多背景信息。
可以使用以下方式显示代码签名详细信息：
codesign --display -vv /Applications/iTunes.app/
...这将产生类似于以下内容的信息（但不会发出修改警告）：
[..]
CDHash=86828a2d631dbfd417600c458b740cdcd12b13e7
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
[..]
可以使用以下方式验证签名：
codesign --verify -vv /Applications/iTunes.app/
这将产生：
/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement
...或（即使只是将一些额外的文件放在应用程序的./Contents/Resources文件夹中）：
/Applications/iTunes.app/: a sealed resource is missing or invalid
...或（可能比上述消息更糟）：
/Applications/iTunes.app/: code or signature modified
代码签名可以追溯到OS 9或更早版本，但是当前的实现是在10.5 Leopard 中引入的。Ars Technica 写道：
代码签名将密码可验证的身份与代码集合相关联，并确保检测到对该代码的任何修改。不保证有关各方的利益。例如，如果您下载由Acme Inc.签名的应用程序，则除了它来自上次从其网站下载东西的声称是Acme Inc.的同一实体之外，您无法证明任何有关该应用程序的信息。
该示例实际上从消费者的角度突出了该技术的最有用的应用。在今天（在10.4 Tiger，AvB中）升级Mac OS X应用程序时，通常会提示用户重新验证是否允许该应用程序访问钥匙串以检索用户名和密码。这似乎是一项很好的安全功能，但实际上所做的只是训练Mac用户每次出现时都盲目单击“始终允许”。实际上，普通用户将要做的事情是，通过反汇编程序运行可执行文件并手动验证代码是否安全？
另一方面，已签名的应用程序可以从数学上证明它确实是您过去表示信任的同一供应商提供的同一应用程序的新版本。结果是对话框结束，要求您确认一个您没有合理方法验证其安全性的选择。
对于10.5 Leopard中的防火墙，Apple 解释：
将应用程序添加到此列表后，Mac OS X将对该应用程序进行数字签名（如果尚未签名）。如果以后修改了该应用程序，系统将提示您允许或拒绝与该应用程序的传入网络连接。大多数应用程序不会自行修改，这是一项安全功能，可将更改通知您。
[..]
允许列表中未由系统信任的证书颁发机构进行数字签名（出于代码签名目的）的所有应用程序接收传入的连接。Leopard中的每个Apple应用程序均已由Apple签名，并允许接收传入的连接。如果您希望拒绝经过数字签名的应用程序，则应先将其添加到列表中，然后再明确拒绝它。
在10.6 Snow Leopard中，后者更为明确（可以禁用），因为“自动允许签名的软件接收传入的连接。允许由有效证书颁发机构签名的软件提供从网络访问的服务”。
（在10.6中，将10.5.1选项“允许所有传入连接”，“仅允许基本服务”和“设置特定服务和应用程序的访问权限”修改为“阻止所有传入连接”或列表的选项。允许的应用程序和选项“自动允许签名的软件接收传入的连接”和“启用隐藏模式”。在10.5.1更新之前，“仅允许基本服务”实际上称为“阻止所有传入的连接”。）
对于（Apple）应用程序，如果某些原因破坏了其原始签名，则可能无法保留该临时签名，并且已知这对configd，mDNSResponder和racoon 造成了麻烦。