Are Mac App Store code sign resource envelopes always version 1?

Question

After the latest email detailing changes on the gatekeeper for 10.10 beta 5 and 10.9.5 , I went and immediately verified my app with the recommended method from TN2206 . To my surprise, since I used no resource rules and built it on Mavericks, it failed:

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

Then, I went on to check the submitted binary inside the Xcode archive, which was promptly rejected, but without the "obsolete resource envelope" warning. I suppose that's because it's signed by the submission certificate.

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

Later on, I checked the resource envelopes themselves:

$ 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

Then the submitted app:

$ 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

As you can see, the Mac App Store downloaded app has only a version 1 resource envelope, even with the submission of a version 2 one. To be sure, I checked my /Application folder and found out that every app I downloaded from the Mac App Store also had a version 1 envelope, even Apple's ones.

Does anyone know whether that's normal, i.e., if the Mac App Store, when re-signing the app, only adds version one envelopes?
Moreover, will that cause problems?
Will that be fixed by Apple?
After that fix, should I resubmit my app?

Answer 1

This issue appears to have been fixed in Mac OS X Yosemite (verified on 10.10.5), but it re-appeared on El Capitan (verified on 10.11.4).

Application bundles can be signed and verified reliably. For example:

$ 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
$

However any attempt to sign a single binary (executable) fails to satisfy system policy (as shown by 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

That includes Apple-provided system binaries such as /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
$

Radar has been submitted - no reaction from Apple yet. The report from Apple has been less than encouraging:

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 2

This is an issue with Mac OSX 10.9.5 and later. Apple will fix this in future release.

Please see my comments for Error when export archive

Answer 3

This is indeed a bug. A opened a radar it was closed as a duplicate, which is open.

Answer 4

My submitted application had also envelope v2 which was replaced by v1 by Apple.

I left "*.dylib" in the Resources folder totally without signature.

Verify that your nested libraries are signed:

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

However, this was not enough.

To fix it I added to additional post-build codesign and pkg creating script. Follow this tutorial

Also make sure that your 3rd party Frameworks are correctly structured (do no omit symbolic links). Check Apple guideline on framework structure

EDIT: Did not work. Bundle is still returned in version 1. Any idea?

Answer 5

The version designator (1 or 2) is more in relation to what version of OS X was used build and sign the code.

Resource Envelopes Version 1 & 2

(Code signatures containing version 1 or version 2 resource envelopes are also known as version 1 signatures or version 2 signatures, respectively)

< OS X v10.9 (version 1)

• Recorded only files in the Resources directory and ignored the rest.
• Ignores symlinks.
• If system is < 10.9 it ignores version 2 resource envelopes and use version 1 exclusively.
• Uses documented signing feature (--resource-rules) to control which files in a bundle should be sealed by a code signature. (deprecated for 10.9+)

OS X v10.9+ (version 2)

• Records nested code (frameworks, dylibs, helper tools and apps, plug-ins, etc.)
• Records substantially all files by default.
• Records symbolic links.
• Generates, by default, both version 2 and version 1 resource envelopes.
• If a 10.9+ system sees a version 1 signature, it performs version 1 validation.
• Always seals all files in a bundle; there is no need to specify this explicitly any more.
• codesign on OS X 10.9+ and later does not show the version 1 resource envelope if a version 2 resource envelope is present, as only the version 2 resource envelope will be used.

To determine which version of resource envelope a code signature has, use 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

• Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.
• For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature.
• Apps signed using previous versions of OS X will need to be re-signed with version 10.9 or later to create version 2 signatures.
• Apps signed with version 2 signatures will work on older versions of OS X.
• If your app is on the Mac App Store, submit your re-signed app as an update.

For OS X version 10.9 or later:

• Only include signed code in directories that should contain signed code.
• Only include resources in directories that should contain resources.
• Do not use the --resource-rules flag or ResourceRules.plist. (your app will be rejected)

To ensure your current and upcoming releases work properly with Gatekeeper, test on OS X version 10.10 (Seed 5 or later) and OS X version 10.9.5.

spctl will only accept Developer ID-signed apps and apps downloaded from the Mac App Store by default. It will reject apps signed with Mac App Store development or distribution certificates.

Use spctl on your app like this:

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

This is the output if your app's signature will be accepted:

Foo.app: accepted

source=Developer ID

➣ source may also be Mac App Store.

If your app's signature only has an obsolete version 1 resource envelope, you'll see this:

Foo.app: rejected

source=obsolete resource envelope

Note: It is necessary to sign code while running OS X Mavericks to get a version 2 signature. The actual code signing machinery is part of the operating system, not the codesign tool. It will not work to copy the codesign tool from Mavericks to an older OS X version.