Developer ID signed apps from 10.10 are rejected on 10.11

Originator:craig.hockenberry
Number:rdar://21927608 Date Originated:21-Jul-2015 02:08 PM
Status:Closed Resolved:
Product:OS X Product Version:10.11 (15A216g)
Classification:Serious Bug Reproducible:Always
 
Summary:
An app signed with a Developer ID using Xcode 6 on 10.10 is rejected on 10.11.

Steps to Reproduce:
1) Download and launch an app signed with a Developer ID on 10.10 using Xcode 6.

Expected Results:
The app should launch normally.

Actual Results:
A dialog is presented saying the app is from an unidentified developer. The spctl utility shows “obsolete resource envelope”.

Regression:
This is a new issue for OS X 10.11.

Notes:

A solution that requires building the app on El Capitan to get a non-obsolete resource envelope presents a problem for the developer:

• We can’t do builds using Xcode 7 running on 10.11: they will not be accepted by the Mac App Store.
• Customers can run our apps on the 10.11 public beta and encounter bugs which need to be fixed.

We end up in a situation where the customer MUST run code from an unidentified developer. For the average customer, this is a bad habit to instill.

The full spctl and codesign output is attached below:

$ spctl --verbose=4 --assess --type execute xScope.app
xScope.app: rejected
source=obsolete resource envelope

$ codesign --verify --verbose=4 xScope.app
--prepared:/Users/craig/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/.
--validated:/Users/craig/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/.
--prepared:/Users/craig/Downloads/xScope.app/Contents/Frameworks/YAML.framework/Versions/Current/.
--validated:/Users/craig/Downloads/xScope.app/Contents/Frameworks/YAML.framework/Versions/Current/.
xScope.app: valid on disk
xScope.app: satisfies its Designated Requirement

$ codesign --display --requirements - --verbose=4 xScope.app
Executable=/Users/craig/Downloads/xScope.app/Contents/MacOS/xScope
Identifier=com.iconfactory.xScope
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=9886 flags=0x0(none) hashes=487+3 location=embedded
Hash type=sha1 size=20
CDHash=863a156f24c0c1c333c8eb1db93ae6b9dfc03d86
Signature size=8516
Authority=Developer ID Application: The Iconfactory
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jul 8, 2015, 10:37:56 AM
Info.plist entries=32
TeamIdentifier=RYQWBTQRPT
Sealed Resources version=2 rules=12 files=402
designated => anchor apple generic and identifier "com.iconfactory.xScope" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = RYQWBTQRPT)

——— — 

Response:

Whenever you show output of the spctl command, use --raw. This produces a plist format that contains *all* the information returned by the assessment layer - potentially much more helpful.

The functional equivalent of spctl --assess is this:

$ codesign -vvv --deep --strict /path

You need --deep because problems are often in nested code, and without --deep codesign won't fully dive in there and check everything.
The --strict option is new for 10.11 and enables additional checks (currently about symlinks) that didn't exist before 10.11.

We intend that code made on 10.10 should pass Gatekeeper on 10.11 as long as it complies with a few extra checks we added in 10.11. The command lines shown above demonstrate how to investigate such problems.

The biggest new restrictions in 10.11 apply to symbolic links - dead links (pointing to nothing) are disallowed, as are links to outside the top bundle (except into /System and /Library). There are some extra checks of Mach-O file formats that shouldn’t matter unless you use non-Xcode tools.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!