首页 文章

Mac App Store代码是否始终标记资源封套版本1？

提问于
浏览 次
13

在最新的电子邮件详细说明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在重新签署应用程序时，只添加第一版信封？
那还会引起问题吗？
Apple会修复吗？
在修复之后，我应该重新提交我的应用程序吗？

macos osx-mavericks code-signing mac-app-store osx-yosemite

5 回答

  • 0

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

    资源信封版本1和2

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

    < OS X v10.9 （版本1）

    • 仅记录Resources目录中的文件，忽略其余文件 .

    • 忽略符号链接 .

    • 如果system <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
[...]

    Changes in OS X 10.9.5 and Yosemite Developer Preview 5

    OS X version 10.9.5+ changes

    • 使用Mavericks之前的OS X版本创建的版本1签名将不再被Gatekeeper识别，并且被认为已过时 .

    • 要使您的应用程序在更新版本的OS X上运行，必须在OS X 10.9或更高版本上签名，因此具有版本2签名 .

    • 使用以前版本的OS X签名的应用程序需要使用版本10.9或更高版本重新签名才能创建版本2签名 .

    • 使用版本2签名签名的应用程序将适用于旧版本的OS X.

    • 如果您的应用程序位于Mac App Store中，请将您重新签名的应用程序作为更新提交 .

    For OS X version 10.9 or later:

    • 仅在应包含签名代码的目录中包含已签名的代码 .

    • 仅包含应包含资源的目录中的资源 .

    • Do not use --resource-rules flag或 ResourceRules.plist . （ your app will be rejected ）

    要确保您当前和即将发布的版本与Gatekeeper一起正常运行，请在OS X版本10.10（种子5或更高版本）和OS X版本10.9.5上进行测试 .

    默认情况下，spctl仅接受从Mac App Store下载的开发者ID签名应用和应用 . 它将拒绝使用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签名 . 实际的代码签名机制是操作系统的一部分，而不是代码签名工具 . 将codeign工具从Mavericks复制到较旧的OS X版本是行不通的 .

    回复于
  • 3

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

    回复于
  • 1

    这个问题似乎已在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.
    回复于
  • 2

    我提交的申请也有信封v2，由Apple取代v1 .

    我在Resources文件夹中完全没有签名就留下了“* .dylib” .

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

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

    但是，这还不够 .

    为了解决这个问题，我添加了额外的post-build codesign和pkg创建脚本 . 关注这个tutorial

    还要确保您的第三方框架结构正确（不要忽略符号链接） . 检查框架structure上的Apple指南

    编辑：没有工作 . Bundle仍然在版本1中返回 . 任何想法？

    回复于
  • 15

    这是Mac OSX 10.9.5及更高版本的问题 . Apple将在未来版本中修复此问题 .

    请参阅我对Error when export archive的评论

    回复于

相关问题