Code Signing error in XCode 8.2.1 - xcode

I have an app that builds on my Mac (running El Capitan) but when I copy the app project folder onto another Mac (running Sierra if that may be the problem) and run the project I get the code signing error:
CodeSign /Users/.../Library/Developer/Xcode/DerivedData/appname-fgarszmikfuloefrynwpohxkvgav/Build/Products/Debug-iphonesimulator/appname.app
cd "/Users/... app path"
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Signing Identity: "-"
/usr/bin/codesign --force --sign - --timestamp=none /Users/.../Library/Developer/Xcode/DerivedData/appname-fgarszmikfuloefrynwpohxkvgav/Build/Products/Debug-iphonesimulator/appname.app
/Users/.../Library/Developer/Xcode/DerivedData/appname-fgarszmikfuloefrynwpohxkvgav/Build/Products/Debug-iphonesimulator/appname.app: resource fork, Finder information, or similar detritus not allowed
Command /usr/bin/codesign failed with exit code 1
New certs and provisioning profiles etc but all that should be fine.
Followed every suggestion I can find on here (specifically Code Sign Error in macOS Sierra Xcode 8 : resource fork, Finder information, or similar detritus not allowed), cleaned, alt-cleaned. Auto manage signing doesn't fix it.
I have paid developer account.
Can anyone suggest what might be causing the problem?

It seems like this error is caused by extended attributes on files in your project.
You can find out which files are causing this failure by running the following command: xattr -lr <path_to_app_bundle>
You can remove the extended attributes using this command: xattr -cr <path_to_app_bundle>
More info here.

We noticed that a .bundle group which was created in XCode version 8.0.0 was later being used in 8.2.1 and once we removed the bundle and re-added it using XCode 8.2.1, the error was gone. Also it may have something to do with the folder name "Resources" in this bundle. I believe this is an XCode bug but don't quote me on it.

Related

Xcode 11, Command CodeSign failed with a nonzero exit code

Ever since updating (against my will) to Xcode 11, I'm getting this error when I try to build my project:
CodeSign /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app (in target 'pplight-ofx-098' from project 'pplight-ofx-098')
cd /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
Signing Identity: "-"
/usr/bin/codesign --force --sign - --entitlements /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/build/pplight-ofx-098.build/Debug/pplight-ofx-098.build/pplight-ofx-098Debug.app.xcent --timestamp=none /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app
/Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app: code object is not signed at all
In subcomponent: /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app/Contents/Frameworks/GLUT.framework
Command CodeSign failed with a nonzero exit code
I've tried cleaning my project, resetting my login keychain, and restarting my computer, but I still get this error... what to do?
I am building an OSX App using OpenFrameworks, not an iOS App. When I build it in Xcode 10.3 works fine with no errors.
The parts of this question that are unique is that this is for Xcode 11, not 10, and none of the answers for that other question worked for me!
I've resolved the same exact problem by:
Add --deep to the "Other Code Signing Flags" in the "Build Settings".
In the "Signing & Capabilities" of your target click on "+ Capability" in the top left corner and choose "Hardened Runtime".
Then turn on "Disable Library Validation" in the list.
I don't really know if there's any drawbacks by using this capability, however my application compiles and works fine both on macOS and iOS.
You can get this error if you have added a folder to your project as a 'folder reference' (the project will have a blue folder logo in Xcode)
Remove the folder (Trash)
Add folder and select 'Create Groups' instead of 'Folder Reference' at the dialog
Add Folder Dialog
I got the same error after I upgraded to XCode-11 this morning. Builds in the simulator but not on device.
This thread helped fix the issue which I summarized below.
https://stackoverflow.com/a/52628909/9286768
Open keychain access.
Lock the 'login' keychain. (right clicking on "login" in the upper left
panel)
Unlock it, enter your PC account password.
Clean Project in the product menu.
Build it Again.
I fixed this by adding --deep to Other Code Signing Flags in the Build Settings > Signing
I had the same issue for all my Carthage Frameworks, the solution is:
Under Target-> [AppName] -> General -> "Frameworks, Libraries and
Embedded Content"
Select "Do Not Embed" for the option next to the problematic
framework.
More info are in this thread
NOTE: this might not fully solved the issue, never forget to try clean the project, restart Xcode even restart Mac sometimes.
I solved the problem as follows:
After adding 2 ".png" files, Xcode (Version 13.2.1 (13C100)) would not compile anymore. I integrated these 2 files in a .rtf file (generated from Xcode) and I succeeded in compiling again. That's how it goes.
I fixed the problem by making sure the Code Signing Identity in Build Settings was correct - not just general Apple Development and then cleaned the Build Folder in in the Product Menu. When I ran it again it built without error.
I resolved a similar error in Xcode 13 by only changing my Base SDK to the latest SDK (i.e. iOS 15).

Ad-Hoc codesigning for device succeeds in Studio, Fails in Jenkins

I have a Xamarin Forms application that supports Android and iOS. I've generated Jenkins builds to compile them. All of the Android builds work. The iOS Debug build compiles fine. The Ad-Hoc build, however, fails to build completely for an iPhone target. It appears to be failing during codesigning. It works if I target the iPhoneSimulator, but if I target iPhone device it fails.
Tool /usr/bin/codesign execution started with arguments: -v --force --sign 81088F8E194139DC4C6CE640716944E41FB0709F --entitlements "/Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/Entitlements.xcent" --deep "/Users/Shared/Jenkins/.jenkins/workspace/{project path}/bin/iPhone/Ad-Hoc/AppName.app"
bin/iPhone/Ad-Hoc/AppName.app : error : /Users/Shared/Jenkins/.jenkins/workspace/{project path}/bin/iPhone/Ad-Hoc/AppName.app: unknown error -1=ffffffffffffffff [/Users/Shared/Jenkins/.jenkins/workspace/{project path}/iDriverMobile.iOS.csproj]
If I open up the Solution in Visual Studio, right in the Jenkins workspace folder so it's using the exact same files, then compilations works fine, which is really frustrating.
Looking at differences between the two outputs, it seems that the working build (from Studio) has AOT output for all of the assemblies that looks like this:
Mono Ahead of Time compiler - compiling assembly /Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/mtouch-cache/32/Build/OpenNETCF.Google.Analytics.dll
The failing build has none of those. Instead, it has a couple lines that look like this:
MTOUCH : warning MT0095: Aot files could not be copied to the destination directory /Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/mtouch-cache/64/Build/Msym/Msym/tmp: Could not start process. [/Users/Shared/Jenkins/.jenkins/workspace/{project path}/AppName.csproj]
The worst part of all of this is that these builds did work, but then I restarted the Mac Mini that Jenkins is running on and things went downhill. I can't figure out what the difference is between what Studio is doing and the command line call to msbuild. They both point to the same binaries.
Additional Information
This still fails with the latest updates as of today (5/24/17). This is the environment:
Mac OS X 10.12.5
List item
XCode 8.3.2
Xamarin.iOS 10.10.0.36
Visual Studio 2017 Community for Mac 7.0.1 (build 24)
Mono 5.0.1.1
What doesn't fix it:
Creating a new Jenkins build
Changing the Jenkins workspace path
Opening up permissions (777) to the entire Jenkins folder
Enabling LLVM
Disabling all linking
Completely uninstalling and re-installing Jenkins
Using xbuild instead of msbuild
Swearing a lot
My middle finger
Try to delete the derived data folder in DerivedData of your app. It looks like YourAPP_ dasfdsfsdafdsasfdsaf, according to this from Apple Developer Forum.
The DerivedData data folder is located at ~/Library/Developer/Xcode/DerivedData/
If this does not work, all the symptoms point to a signing certificate (also called, signing identity) issue.
It seems like when it was compiled from command line, /usr/bin/codesign can not access signing identity 81088F8E194139DC4C6CE640716944E41FB0709F. It could be many different reasons, unfortunately:
keychain was locked
codesign is not allowed to access the signing
identity.
multiple identities exist in keychain and wrong signing
identity was selected
Wrong provision
profile was matched for Ad Hoc build.
Try to add following code snippets before running msbuild, assuming your signing identity is in keychain ~/Library/Keychains/login.keychain:
security unlock-keychain -p <password> ~/Library/Keychains/login.keychain
security set-keychain-settings -l -u -t 3600 ~/Library/Keychains/login.keychain
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k -p <password> ~/Library/Keychains/login.keychain
It is not a good idea to have keychain password stored in the build script, you can follow this guide to hide them.

codesigning issues with multiple binaries on the same path

Ive been trying to create a build of my program signed with my mac developer ID but i keep getting the error message "Multiple binaries share the same codesign path". I have checked the code signatures on each of the attached frameworks using the codesign terminal ultity and there doesnt seem to be any codesigning issues.If it helps the frameworks which seem to causing the problem are SDL2, SDL2_image, SDL2_mixer and SDL2_ttf. Also i am running Xcode 6.1.1 on yosemite 10.10.2
Open your Archive folder and delete all previous built version before your code signing was made. Try again after.

code has no resources but signature indicates they must be present

I have a Qt (5.3.1) application that worked fine until the latest update in codesign, but now gatekeeper throws this error:
code has no resources but signature indicates they must be present
(the command I used to verify the app bundle is: spctl -at exec -vv path/to/.app)
The deployment script builds the app bundle, invokes macdeploy, copies all the missing qt info.plist files and then it invokes codesign:
codesign --force --deep --verify --verbose --no-legacy-signing --sign "signing authority string" /path/to/.app
The --no-legacy-signing was added because of the outdated resource envelope error. Nothing else was changed since it worked the last time.
Building and codesign are done on OS X Yosemite, Xcode 6.0.1 is installed. It's not the latest yosemite version, I'm not sure which one it actually is (I did not set up the machine, but I do see the update center is offering an upgrade to developer preview 8).
Has anyone encountered this error?
I have had the same issue that you had. This is what you need to do in order to fix the issue:
You need to correct the Framework structure after you call the macdeployqt utility. The required structure can be found here: Anatomy of Framework Bundles
Some of the Qt Frameworks contain bad CFBundleExecutable information. The executable name ends with _debug. (notably these framework: QtPrintSupport, QtPositioning, QtQml and QtQuick)
You can find my complete solution here: Unable to sign app bundle using Qt frameworks on OS X 10.10

osx 10.9.5 code signing V2 - signing a framework with: bundle format is ambiguous

I'am trying to code sign an app bundle on osx mavericks 10.9.5 with format v2. On previous testing the signing on 10.9.5 (13F12) all went well, all frameworks could be signed without error.
Now, on 13F34, the frameworks could not be signed any more. When i try to sign the first framework with:
codesign -f -v -s "Developer ID Application: MY AG" "My.app/Contents/Frameworks/4DJavaScript.framework"
then the error occurs:
My.app/Contents/Frameworks/4DJavaScript.framework: bundle format is ambiguous (could be app or framework)
When I try to code sign the only version (A) of the framework, the signing succeeds, but on signing the main app the error on the framework reappears.
On looking into the info.plist file of the framework there is (in my sense) the correct entry for the type set:
Bundle OS Type code FMWK
Any suggestions on how to code sign a framework correctly on 10.9.5-13F34?
Thanks, Peter
Your answer didn't work for me so I post mine.
If you previously copied frameworks with cp -r command you will have this problem. With cp -a this problem doesn't appear. That's happening because of different way of resolving symlinks in these two options.
Immediately after posting the bounty on this question, I figured it out. Signing the current version of the framework directly does the trick:
codesign -f -v -s "Developer ID Application: My Dev ID" MyFramework.framework/Versions/Current
I was using electron-packager and needed to use the --no-deref-symlinks flag and bam working for me
I ran into the same problem. In my case the problem was that the .app file I was trying to codesign was stroed in a dropbox folder.
Apparently, dropbox resolves symbolic links by default, i.e. symlinks are completely replaced by the data they point to. Read about it here.
The codesign command cannot recognize the format of the bundle after dropbox resolves the symlinks.
The solution is to not store the bundle you are trying to codesign in a dropbox folder.

Resources