Macos Mac应用商店代码签名资源信封是否始终为版本1?

Macos Mac应用商店代码签名资源信封是否始终为版本1?,macos,osx-mavericks,code-signing,mac-app-store,osx-yosemite,Macos,Osx Mavericks,Code Signing,Mac App Store,Osx Yosemite,在收到最新的电子邮件,详细介绍了10.10 beta 5和10.9.5版的gatekeeper的更改之后,我立即用TN2206推荐的方法验证了我的应用程序。令我惊讶的是,由于我没有使用任何资源规则,而是基于Mavericks构建的,所以失败了: $ spctl -a -t exec -v /Applications/MyApp.app/ /Applications/MyApp.app/: rejected source=obsolete resource envelope 然后,我继续检查Xc

在收到最新的电子邮件,详细介绍了10.10 beta 5和10.9.5版的gatekeeper的更改之后,我立即用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资源信封也是如此。可以肯定的是,我检查了我的/应用程序文件夹,发现我从Mac应用商店下载的每个应用程序都有一个版本1的信封,甚至是苹果的

是否有人知道这是否正常,即Mac App Store在重新签署应用程序时是否只添加版本1信封?
此外,这会导致问题吗?
这将由苹果公司解决吗?
在修复之后,我是否应该重新提交我的应用程序?

版本指示符(1或2)与使用的OS X版本更相关—生成并签署代码

资源信封版本1和2 (包含版本1或版本2资源信封的代码签名) 也称为版本1签名或版本2签名, (分别)

(第1版)

  • 仅记录资源目录中的文件,而忽略其余文件
  • 忽略符号链接
  • 如果系统<10.9,则忽略版本2资源封套,仅使用版本1
  • 使用文档化签名功能(
    --资源规则
    )来控制捆绑包中的哪些文件应该由代码签名密封。(不推荐用于10.9+)
操作系统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和优胜美地开发者预览版5的变化

OSX版本10.9.5+的更改

  • 使用Mavericks之前的OSX版本创建的版本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
    标志或
    resource rules.plist
    。(您的应用将被拒绝
为了确保您当前和即将发布的版本能够与Gatekeeper正常工作,请在OSX版本10.10(Seed 5或更高版本)和OSX版本10.9.5上进行测试

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

在应用程序上使用
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

注意:运行OSX Mavericks时需要对代码进行签名,以获得版本2签名。实际的代码签名机制是操作系统的一部分,而不是代码签名工具。将代码设计工具从Mavericks复制到较旧的OS X版本是行不通的。

我提交的应用程序也有信封v2,由苹果公司用v1代替

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

验证嵌套库是否已签名:

codesign --display --verbose=4 library.dylib
library.dylib: code object is not signed at all 
然而,这还不够

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

还要确保第三方框架的结构正确(不要忽略符号链接)。检查框架上的Apple指南


编辑:不工作。捆绑包仍然在版本1中返回。有什么想法吗?

这确实是一个bug。A打开了一个雷达,它作为一个副本关闭,该副本是打开的。

这是Mac OSX 10.9.5及更高版本的一个问题。苹果将在未来的版本中解决这个问题

有关详细信息,请参阅我的评论

这个问题似乎已经在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所示):

其中包括苹果提供的系统二进制文件,如/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
$
雷达
$ 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.