21

I've just updated my xcode install to use xcode 6.0.1 in order to start compiling my app for ios8 devices. For some reason I am not able to ever sign the app file correctly that is generated using the following:

xcodebuild -project GrantM/GrantM.xcodeproj -configuration Release

it compiles the code and appears to be fine, but running:

/usr/bin/codesign --verify -vvvv GrantM/GrantM.app

give me:

Program /usr/bin/codesign returned 1 : [GrantM/GrantM.app: resource envelope is obsolete]
Codesign check fails : GrantM/GrantM.app: resource envelope is obsolete

checking that the code was signed at all using: /usr/bin/codesign -dv GrantM/GrantM.app

returns:

Executable=Documents/GrantM/GrantM/GrantM.app/GrantM
Identifier=com.grantapps.GrantM
Format=bundle with Mach-O universal (armv7 (16777228:0))
CodeDirectory v=20200 size=647 flags=0x0(none) hashes=23+5 location=embedded
Signature size=4336
Signed Time=24 Sep 2014 12:54:53 pm
Info.plist entries=34
TeamIdentifier=N3KKU46JLY
Sealed Resources version=2 rules=5 files=55
Internal requirements count=1 size=180

has anyone else run into similar issues on OSX 10.9.5 & xcode 6.0.1? Or am I just being a bit stupid and doing something obvious wrong?

additionally, I was able to find the debug version of the app generated in xcode and could sign that successfully, but it being a debug version it won't work for distrobution. I can't even manually sign the xcodebuild generated app file.

thanks for any help or advice in advance.

Grantism
  • 374
  • 2
  • 3
  • 11
  • +1, My App was able to be installed and run in iOS7/iPhone4/5, though the codesign verification failed. No idea if any patential risk. I collected some information from both official and non-official, but I had not resolved the problem yet. http://stackoverflow.com/questions/26082784/ios-codesign-verification-failed-while-upgrading-to-os-x-10-9-5 – firebear Sep 28 '14 at 08:05

5 Answers5

28

If you are using Mac OSX 10.9.5 or later, then there is an issue with OS codesigning with V2 signature.

So, use --no-strict flag with codesign --verify to get over this error.

If you're using PackageApplication to create an .ipa file, then

Edit the PackageApplication perl script tool using vi PackageApplication command and update codesign function occurrences to pass --no-strict parameter.

Example:

my $result = runCmd("/usr/bin/codesign", "--verify", "--no-strict", "-vvvv", , $plugin );

I was facing same and got the following response from Apple Dev Team. The issue is resolved for me.

The command line tool “codesign” has changed in 10.9.5 and 10.10, you need to pass “--no-strict” option to the command, (the problem has been reported and will be fixed). To workaround the problem, please save a copy and modify PackageApplication to pass “—no-strict” to codesign, you can locate PackageApplication by running the following: xcrun -sdk iphoneos -f PackageApplication

techraf
  • 64,883
  • 27
  • 193
  • 198
Omkar
  • 1,108
  • 10
  • 19
  • 1
    Does this also solve the issue for xcodebuild? I mean, does xcodebuild use PackageApplication? – RonaldPK Oct 08 '14 at 10:44
  • 1
    Overall the issue is with Mac OSX 10.9.5 and later and codesign tool. xcodebuild doesn't use PackageApplication directly unless you specify some postscript to create an ipa file. If you are using xscrum with PackageApplication then you will have to modify PackageApplication to make it working in Mac OSX 10.9.5 and later. – Omkar Oct 09 '14 at 08:25
  • 1
    Thanks. I was indeed using xcodebuild to create an IPA from an xcarchive. I added --no-strict in PackageApplication, and now 'Checking the app' returns 'valid on disk' and 'satisfies its Designated Requirement'. Sounds much better to me than 'resource envelope is obsolete'. – RonaldPK Oct 11 '14 at 11:16
  • Thanks. I found there is 2 places of codesign calling in PackageApplication. add the --no-strict in the part of 'Checking original app' could workaround the problem. – firebear Oct 15 '14 at 03:52
  • Adding "--no-strict" fixed it for me. I assume the IPA won't get rejected upon submit? – Jay Q. Oct 21 '14 at 02:14
  • I asked the same question to Apple Dev Team, they said "You should be able to upload it". I'm also in process of getting my app signed from Apple. Once done I'll update the post. – Omkar Oct 21 '14 at 03:07
  • 2
    @JayQ. Yes, we followed above steps to generating ipa file and our ipa got accepted by Apple. :) – Omkar Nov 03 '14 at 09:35
  • THANK YOU! You saved the day - this turned out to be was what was preventing our app from being accepted. Has this been fixed in Yosemite command line tools? Our machine was running Mavericks. – dadude999 Dec 10 '14 at 22:47
  • We can see this issue in Yosemite as well. – Omkar Dec 12 '14 at 06:34
  • Running a less-strict `codesign` verification check doesn't solve the problem for me. The bundle (in my case an OS X installer `mpkg`) still fails a check carried out by `spctl` and, most importantly, doesn't get through Gatekeeper. – Rich Jun 02 '15 at 09:15
  • Are you running codesign on Mac OSX 10.10? If not, then you should do it otherwise Gatekeeper will catch you. – Omkar Jun 05 '15 at 08:44
  • This solution should worry us a lot. Strict code signing is important, otherwise malicious apps could become the norm. – Douglas Held Oct 12 '15 at 13:56
4

I've got a Jenkins CI system setup to provide automated builds of our iOS app from our git repo. In addition I also upload / submit a built to Crashlytics for crash log monitoring.

Everything worked fine with Xcode 6.0 GM, but since installing Xcode 6.0.1 the upload to Crashlytics fails with the same error. I'm asking for their assistance about this.

Part of my build job does use xcodebuild to generate an archive of the app, and from that I also use PackageApplication to get an .ipa file, and PackageApplication does issue the codesign command and that does NOT fail. I am using a distribution build, rather than debug too.

Here is the command I use to clean / archive the app in my job:

xcodebuild clean archive -scheme MyScheme -target MyTarget -sdk iphoneos -configuration AdHoc CODE_SIGN_IDENTITY="iPhone Distribution: MyCompany" PROVISIONING_PROFILE="UDID_Of_Provisioning_Profile"

Here is the command I use to package / get an .ipa file of the app from within the generated archive:

xcrun -sdk iphoneos PackageApplication "Path/to/MyApp.app" -o "/Path/To/MyApp.ipa" --sign "iPhone Distribution: MyCompany" --embed "Path/To/UDID_Of_Provisioning_Profile.mobileprovision"

Try modifying those to suit your setup and see if you get the same error.

Sharkus
  • 175
  • 1
  • 7
  • After much frustration I managed to track the actual issue down. It appears that one of the certificates used in the signing process had quietly expired. creating a new profile fixed it for me. for you, try adding the --no-strict flag to your build flags (I did it in "other code signing flags" section of build settings in xcode) – Grantism Sep 25 '14 at 23:24
  • 1
    I have the same issue but my certificates are not expired – firebear Sep 28 '14 at 08:13
  • How about multiple target app like Watchkit, watch extension, Siri kit Siri UI extension involved. Can advise me some script. I have tried to make an IPA but API installation error is thrown on device copying :( – codelover Dec 06 '17 at 13:04
1

In my case, I verified every framework and dylib I used to find out which is rejected, then resign this very framework or dylib and the whole app saved my ass.

Nix Wang
  • 814
  • 10
  • 18
1

Follow these steps to avoid this error.

  1. Remove CFBundleResourceSpecification = ResourceRules.plist from Info.plist
  2. Avoid --resource-rules in the codesign line and do the code signing.
  3. Verify App: codesign --verify -vvvv Payload/*.app
Febin
  • 161
  • 2
  • 3
0

In OS 10.10, I have to remove --resource-rules in the codesign line

my @codesign_args = ("/usr/bin/codesign", "--force", "--preserve 
metadata=identifier,entitlements","--sign", $opt{sign});
Ram
  • 3,092
  • 10
  • 40
  • 56
Vid
  • 29
  • 1
  • 1
    Can you explain a bit more what it means and why it is necessary? – evenro Oct 29 '14 at 00:01
  • 1
    "Do not use the `--resource-rules` flag or `ResourceRules.plist`. They have been obsoleted and will be rejected." -- From [Apple docs about 10.9.5 changes](https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205). – Dmitry Isaev Dec 25 '14 at 14:46
  • I also want to remove the --resource-rules from codesign. Please tell me how did you remove that. – Rashmi Ranjan mallick Jan 05 '15 at 14:29