macos - Mac App Store 代码签名资源信封是否始终为版本 1？

Question

在最新的电子邮件详细说明了 10.10 beta 5 和 10.9.5 的网守更改后，我立即使用 TN2206 推荐的方法验证了我的应用程序。令我惊讶的是，由于我没有使用资源规则并在 Mavericks 上构建它，所以它失败了：

$ spctl -a -t exec -v /Applications/MyApp.app/
/Applications/MyApp.app/: rejected
source=obsolete resource envelope

然后，我继续检查 Xcode 存档中提交的二进制文件，该文件立即被拒绝，但没有“过时的资源信封”警告。我想那是因为它是由提交证书签名的。

$ spctl -a -t exec -v Products/Applications/MyApp.app/
Products/Applications/MyApp.app/: rejected

后来，我自己检查了资源信封：

$ codesign -d -v  /Applications/MyApp.app/
Executable=/Applications/MyApp.app/Contents/MacOS/MyApp
Identifier=my.app.id
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=14108 flags=0x200(kill) hashes=697+5 location=embedded
Signature size=4169
Info.plist entries=34
TeamIdentifier=not set
Sealed Resources version=1 rules=5 files=82
Internal requirements count=1 size=220

然后提交的应用程序：

$ codesign -d -v  Products/Applications/MyApp.app/
Executable=/Users/jorgepeixotovasquez/Library/Developer/Xcode/Archives/2014-07-09/myapp 09-07-14 00.34.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/myApp
Identifier=my.app.id
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=14123 flags=0x0(none) hashes=697+5 location=embedded
Signature size=4393
Signed Time=09/07/2014 00:34:08
Info.plist entries=34
TeamIdentifier=F2XAAD6WWR
Sealed Resources version=2 rules=12 files=85
Internal requirements count=1 size=220

如您所见，Mac App Store 下载的应用程序只有版本 1 的资源信封，即使提交了版本 2 的资源包。可以肯定的是，我检查了我的 /Application 文件夹，发现我从 Mac App Store 下载的每个应用程序都有一个版本 1 的信封，甚至是 Apple 的信封。

有谁知道这是否正常，即如果 Mac App Store 在重新签署应用程序时只添加版本一信封？
此外，这会引起问题吗？
苹果会解决这个问题吗？
修复后，我应该重新提交我的应用程序吗？

Answer 1

版本指示符（1 或 2）更多地与使用的 OS X 版本构建和签署代码有关。

资源信封版本 1 和 2

（包含版本 1 或版本 2 资源信封的代码签名也分别称为版本 1 签名或版本 2 签名）

< OS X v10.9 (版本 1)

• 仅记录资源目录中的文件，忽略其余文件。
• 忽略符号链接。
• 如果系统小于 10.9，它会忽略版本 2 资源信封并专门使用版本 1。
• 使用文档签名功能 ( --resource-rules) 来控制捆绑包中的哪些文件应由代码签名密封。（10.9+ 已弃用）

OS X v10.9+（版本 2）

• 记录嵌套代码（框架、dylib、辅助工具和应用程序、插件等）
• 默认情况下几乎记录所有文件。
• 记录符号链接。
• 默认情况下，生成版本 2 和版本 1 资源包络。
• 如果 10.9+ 系统看到版本 1 签名，它将执行版本 1 验证。
• 始终将所有文件密封在一个包中；不再需要明确指定这一点。
• 如果存在版本 2 资源包络，则 OS X 10.9+ 及更高版本上的 codesign 不会显示版本 1 资源包络，因为只会使用版本 2 资源包络。

要确定代码签名具有哪个版本的资源信封，请使用codesign -dv：

$ codesign -dv My.app/
[...]
Sealed Resources version=2 rules=15 files=53
[...]

OS X 10.9.5 和 Yosemite Developer Preview 5 中的更改

OS X 版本 10.9.5+ 更改

• 使用 Mavericks 之前的 OS X 版本创建的版本 1 签名将不再被 Gatekeeper 识别并被视为过时。
• 为了让您的应用程序在 OS X 的更新版本上运行，它们必须在 OS X 10.9 或更高版本上签名，因此具有版本 2 签名。
• 使用以前版本的 OS X 签名的应用程序需要使用 10.9 或更高版本重新签名才能创建版本 2 签名。
• 使用第 2 版签名签名的应用程序将在旧版本的 OS X 上运行。
• 如果您的应用在 Mac App Store 上，请将您重新签名的应用作为更新提交。

对于 OS X 10.9 或更高版本：

• 仅在应包含签名代码的目录中包含签名代码。
• 仅在应包含资源的目录中包含资源。
• 不要使用标志--resource-rules或ResourceRules.plist. （您的应用程序将被拒绝）

为确保您当前和即将发布的版本与 Gatekeeper 一起正常工作，请在 OS X 版本 10.10（Seed 5 或更高版本）和 OS X 版本 10.9.5 上进行测试。

spctl 默认只接受开发者 ID 签名的应用程序和从 Mac App Store 下载的应用程序。它将拒绝使用 Mac App Store 开发或分发证书签名的应用程序。

spctl像这样在您的应用上使用：

$ spctl -a -t exec -vv Foo.app

如果您的应用程序的签名将被接受，则输出如下：

Foo.app: accepted

source=Developer ID

➣ 来源也可能是 Mac App Store。

如果您的应用程序签名只有一个过时的版本 1 资源信封，您将看到：

Foo.app: rejected

source=obsolete resource envelope

注意：必须在运行 OS X Mavericks 时对代码进行签名才能获得版本 2 签名。实际的代码签名机制是操作系统的一部分，而不是代码签名工具。将 Codesign 工具从 Mavericks 复制到较旧的 OS X 版本是行不通的。

Answer 2

这确实是一个错误。A打开了一个雷达，它作为一个副本关闭，它是打开的。

Answer 3

此问题似乎已在 Mac OS X Yosemite 中得到修复（在 10.10.5 上验证），但它重新出现在 El Capitan 上（在 10.11.4 上验证）。

应用程序包可以被可靠地签名和验证。例如：

$ codesign --deep --strict -r="designated => anchor trusted" -s MouseSigner ebe.app
$ codesign -vvvv ebe.app
ebe.app: valid on disk
ebe.app: satisfies its Designated Requirement
$ codesign -dvvv ebe.app
Executable=/Volumes/ebe/ebe.app/Contents/MacOS/ebe
Identifier=org.burrow.ebe
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=29151 flags=0x0(none) hashes=905+4     location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=b1c33........
CandidateCDHash sha256=384e........
Hash choices=sha1,sha256
CDHash=384e........
Signature size=2699
Authority=MouseSigner
Authority=Forest CA
Signed Time=Apr 10, 2016, 14:49:44
Info.plist entries=8
TeamIdentifier=not set
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=36
$ spctl -a -vvv -t exec ebe.app
ebe.app: accepted
source=Forest CA
origin=MouseSigner
$

但是，任何对单个二进制文件（可执行文件）进行签名的尝试都无法满足系统策略（如 spctl 所示）：

$ codesign -dvv foo-ssl
Executable=/Users/me/src/foo-ssl
Identifier=foo-ssl
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=280 flags=0x0(none) hashes=3+4 location=embedded
Signature size=2699
Authority=MouseSigner
Authority=Forest CA
Signed Time=Apr 9, 2016, 00:02:21
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=44
$ spctl -a -vvv -t exec foo-ssl
foo-ssl: rejected
source=obsolete resource envelope
origin=MouseSigner

这包括 Apple 提供的系统二进制文件，例如 /usr/bin/perl：

$ codesign -dvv /usr/bin/perl
Executable=/usr/bin/perl
Identifier=com.apple.perl
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=223 flags=0x0(none) hashes=6+2 location=embedded
Platform identifier=1
Signature size=4105
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64
$ spctl -a -vvv -t exec /usr/bin/perl
/usr/bin/perl: rejected
source=obsolete resource envelope
origin=Software Signing
$

雷达已提交 -苹果还没有任何反应。苹果的报告并不令人鼓舞：

Please know that our engineering team has determined that this issue
behaves as intended based on the information provided.

Gatekeeper (as of 10.11.4) rejects anything that isn’t an app (or “like” an
app, such a widget). This is part of a general hardening effort.

Answer 4

我提交的申请也有信封 v2，被 Apple 替换为 v1。

我将“* .dylib”完全留在资源文件夹中，没有签名。

验证您的嵌套库是否已签名：

codesign --display --verbose=4 library.dylib
library.dylib: code object is not signed at all 

然而，这还不够。

为了修复它，我添加了额外的构建后代码设计和 pkg 创建脚本。按照本教程

还要确保您的第 3 方框架结构正确（不要省略符号链接）。检查 Apple 框架结构指南

编辑：没用。Bundle 在版本 1 中仍然返回。知道吗？

Answer 5

这是 Mac OSX 10.9.5 及更高版本的问题。Apple 将在未来的版本中解决此问题。

请参阅我对 导出存档时出错的评论