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 签名， 分别）

（版本 1）

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

OS X v10.9+（第 2 版）

• 记录嵌套代码（框架、dylib、帮助工具和应用程序、插件等）
• 默认记录几乎所有文件。
• 记录符号链接。
• 默认情况下生成版本 2 和版本 1 的资源信封。
• 如果 10.9+ 系统看到版本 1 签名，它会执行版本 1 验证。
• 始终将所有文件密封在一个包中；无需再明确指定。
• 如果存在版本 2 资源包络，OS X 10.9+ 及更高版本上的代码设计不会显示版本 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（种子 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
$

雷达已提交 - Apple 尚未做出任何反应。 Apple 的报告并不令人鼓舞：

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”留在了 Resources 文件夹中，完全没有签名。

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

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

但是，这还不够。

为了修复它，我添加了额外的构建后代码设计和 pkg 创建脚本。关注这个tutorial

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

编辑：没用。 Bundle 在版本 1 中仍然返回。有什么想法吗？

Answer 5

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

请查看我的 cmets Error when export archive