I put a executable binary XXX in my app works on MacOS ,and code sign it. My app will use this service through port.
Executable binary XXX will register a service through plist file after install my app , plist file contains DYLD_LIBRARY_PATH which tells executable binary where to find the dylib to use.
launchctl load -wF "$HOME/Library/LaunchAgents/local.plist"
launchctl start local
Here is the problem:
it worked fine after i build a app.
but when i signed it all and notarized, then open my app to use ,it would get errors as follow:
dyld: Library not loaded: ##HOMEBREW_PREFIX##/opt/libev/lib/libev.4.dylib
Referenced from: /Users/buffer/Library/Application Support/XXX
Reason: unsafe use of relative rpath ##HOMEBREW_PREFIX##/opt/libev/lib/libev.4.dylib in /Users/buffer/Library/Application Support/XXX with restricted binary
It will use default dylib path（##HOMEBREW_PREFIX##/opt/libev/lib/libev.4.dylib） that comes from executable binary XXX, not my custom DYLD_LIBRARY_PATH. Apple has restricted binary use such unsafe relative rpath.
Updated:
My app will start a shell script to install executable binary XXX and dylib ,
Executable binary XXX will register as a service to start and stop through plist as below
launchctl load -wF "$HOME/Library/LaunchAgents/local.plist"
launchctl start local
My executable binary XXX path and DYLD_LIBRARY_PATH both located at /Users/buffer/Library/Application Support/myApp/*** , it start separately as a service for my app to use.
I have found some situations below:
1.I have a same executable binary XXX signed at 2018-09-25 , it works fine.
2.And executable binary XXX that have not been signed worked fine too.
3.But when i have signed executable binary XXX now and use it with dylib , it will get errors above.
So ，whether apple sign algorithm has changed and make this error occurs ?
here is my code sign command for now as below:
codesign --force --options runtime --sign "Developer ID Application: ****" XXX
Finally:
I have found problem,
Apple require developer enable Hardened runtime for every app to notrize now. if you enable Hardened runtime but not specify entitlements , then some permissions will be disabled as default .
My permission for use DYLD Environment Variables has been disabled as default
you can check this document below
Hardened Runtime Entitlements
If you customize code sign workflow like me , you can specify entitlements when you codesign as below,entitlements.plist contains permissions you want enable
codesign --force --options runtime --entitlements /Users/buffer/Desktop/entitlements.plist --sign "Developer ID Application: ****" XXX
As of macOS 10.10.4, for security reasons, you are not allowed to use a dylib outside the directories that Apple deems as secure as, for example:
/System/
/usr/bin/
/Library/Frameworks/
The code signing documentation entitled "Checking Gatekeeper Conformance" expressly states that:
Beginning with macOS 10.10.4, Gatekeeper verifies that no libraries are loaded from outside an app bundle. If an app uses #rpath or an absolute path to link to a dynamic library outside of the app, Gatekeeper rejects the app. This restriction applies to the app’s main executable and any other executable in the bundle, including libraries. This restriction applies even if the path does not exist (which normally causes the dynamic linker to fall back to a library inside the bundle). The error will appear in the system log, with a message like the following for an app MyApp.app trying to link against the library libLibrary.dylib in the nonstandard location /foo
Thus, you should embed your dylib inside your application.
Apparently, another possible solution is to use a signed installer to install a common framework at /Library/Frameworks/, but this solution was offered by DTS, and is apparently not part of the official documentation.
I learned from Apple DTS that there is a known bug in macOS Catalina 10.15.3 and earlier (already fixed in 10.15.4 beta) wherein a notarized command line app that links against a .dylib outside of its bundle (and command line apps are typically not in a bundle) will still fail Gatekeeper checks that trigger when the quarantine flag is set on the command line executable.
To workaround the problem, Apple DTS recommends:
The easiest workaround is to sign your tool with both the hardened runtime and library validation flags.
That is, change your invocation of codesign from this:
% codesign -s …stuff… -o runtime …stuff… helloworld
to this:
% codesign -s …stuff… -o runtime,library …stuff… helloworld
Explicitly setting the library flag disables this Gatekeeper check and allows your tool to run on macOS 10.15.{0,1,2,3}. Please make a note to remove this flag once 10.15.4 is released and widely adopted.
Every time I build a console is showing this message.
CodeSign /Users/admin/Desktop/AppStoreBuild/Project201/build/Debug-iphonesimulator/Project.app (in target: Desker)
cd /Users/admin/Desktop/AppStoreBuild/Project201
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
Signing Identity: "-"
/usr/bin/codesign --force --sign - --entitlements /Users/admin/Desktop/AppStoreBuild/Project201/build/Project.build/Debug-iphonesimulator/Project.build/Project.app.xcent --timestamp=none /Users/admin/Desktop/AppStoreBuild/Project201/build/Debug-iphonesimulator/Project.app
/Users/admin/Desktop/AppStoreBuild/Project201/build/Debug-iphonesimulator/Project.app: resource fork, Finder information, or similar detritus not allowed
Command CodeSign failed with a nonzero exit code
...
Is there any way to identify the cause of this failure? It's showing Signing Identity: "-" when I try to run in the simulator also. why do we need signing identity in simulator? And one more thing is if I quit Xcode and restart, it will build properly when I change code or add a method will again build failing.
I had that problem and Xcode failed to compile on the device, but on simulator, it worked fine.
I solved with these steps:
Open keychain access.
Lock the 'login' keychain.
Unlock it, enter your PC account password.
Clean Project in the product menu.
Build it Again.
And after that everything works fine.
None of the listed solutions worked for me. In another thread it was pointed out that including a folder named "resources" in the project causes this error. After renaming my "resources" folder, the error went away.
For some people this happens after adding a .png file to an existing .scn assets folder, plus also a .wav file.
Xcode, owing to increased security, doesn't like extensions on files. You can fix these one at a time by cd'ing into the directory where the file is and removing their extended file attributes using the 'xattr' command in Terminal.
To Remove All Extended Attributes On a Single File
Use xattr with the -c flag to "clear" the attributes:
xattr -c yourfile.txt
To Remove All Extended Attributes On Many Files
To recursively remove extended attributes on all files in a directory, combine the -c "clear" flag with the -r recursive flag:
xattr -rc /path/to/directory
Fore more detail, see
How do I remove the "extended attributes" on a file in Mac OS X?
This solution will also help when getting the code signing error: "resource fork, Finder information, or similar detritus not allowed."
Apple documentation: https://developer.apple.com/library/archive/qa/qa1940/_index.html
Fix
Remove extended file attributes in your resource files for good, not in the compiled application bundle:
Open Terminal
Change directory to the root of your source files
$ cd /Users/rjobidon/Documents/My\ Project
List all extended attributes
$ xattr -lr .
Remove all extended attributes
$ xattr -cr .
Xcode errors
"Command CodeSign failed with a nonzero exit code"
"Resource fork, Finder information, or similar detritus not allowed"
Cause
Apple introduced a security hardening change, thus code signing no longer allows any file in an app bundle to have an extended attribute containing a resource fork or Finder info.
Sources
https://developer.apple.com/library/archive/qa/qa1940/_index.html
This happened to me just today, only after I added a .png image with 'hide extension' ticked in the get info. (Right click image) Ths image was added to the file directory of my Xcode project.
When unticked box and re-adding the the .png image to directory of Xcode, I then Cleaned and Built and worked fine after that, a very strange bug if you ask me.
Try cleaning the project:
1. shift + cmd + k
2. shift + cmd + Alt + k
Then try to run your project again. Hope this will fix the problem.
None of the popular solutions worked.
In my case, I resolved the error by going into the
XCode -> Preferences -> Accounts -> Manage Certificates
and added a (+) to iOS development.
This issue happened to me after adding .dae and .png files and converting .dae with XCode Editor to SceneKit scene file format (.scn).
After doing some more research I found the solution here - https://forums.developer.apple.com/thread/109951#336225
Steps to solve the issue:
In XCode go to Preferences
Click on Locations tab
In Command Line Tools select from the drop down XCode 10.1
In Xcode: Go to Preferences Logout of the current user.
Close Xcode
In Keychain: Go to Login and All items
- Sort by kind
- remove "Apple Worldwide Developer Relation Certification Authority"
- remove "Developer ID Certification Authority"
- remove "iPhone Developer ...."
Open Xcode
Go to Preferences and Login to you user apple account
This will reload your developer certificates you previous deleted
Rebuild the project (Should be a successful build)
Run the build on your native device
This is because Code signing no longer allows any file in an app bundle to have an extended attribute containing a resource fork or Finder info.
To see which files are causing this error, go to .app folder, normally is like: /Users/XXXX/Library/Developer/Xcode/DerivedData/MyProject-ckbzynxqjmstxigbdwwkcsozlego/Build/Products/Debug-maccatalyst/ (mine is Catalyst project)
In Terminal,
cd <above path>
xattr -lr .
You will see some files has extended attribute:
./MyProject.app/Contents/Resources/shopping_cart.png: com.apple.lastuseddate#PS:
00000000 BE 31 D5 5E 00 00 00 00 D0 40 FE 39 00 00 00 00 |.1.^.....#.9....|
Then go to your project folder or referenced folder for those files, remove extended attribute:
cd /Users/XXXX/Work/MyProject
xattr -cr .
After clean all referenced folders, go to Xcode and rebuild.
The solution for me was restarting macOS without saving
I'm unsure of what causes this issue but one method I used to resolve the porblem successfully was to run pod update on my cocoa pods.
The error (for me anyway) was showing a problem with one of the pods signing. Updating the pods resolved that signing issue.
pod update [PODNAME] //For an individual pod
or
pod update //For all pods.
Hopefully, this will help someone who is having the same "Command CodeSign failed with a nonzero exit code" error.
In my case was the following errors lines:
Signing Identity: "-"
…..mobile.app: resource fork, Finder information, or similar detritus
not allowed
Command CodeSign failed with a nonzero exit code
the problem was that in the resources folder I had some files with .png extension, which was hidden on the defaults.
Find file in FINDER, mark it -> cmd+i -> unchek Hide extension
after that, return in Xcode -> kmd + shift + K and rebuild.
I hope I've been helpful!
For me the solution was the following, having the "Automatically manage sign" flag on:
in the team drop-down of the target, select "None"
re-select the correct development team
After trying almost every suggestion, I found that this works, I guess because Xcode sets up the signing stuff from scratch.
After trying everything, my solution was removing some PNG files, build and run (ok) and adding again the PNG images. Weird!
I will post my solution. This solution worked for me, since none of the previous worked. The issue first occurred right after last update of XCode cli toolset (not sure if this is the confirmation bias).
I tried some of the instructions (ie. Unlock Keychain Trick).
What worked for me in a case of error:
Command CodeSign failed with a nonzero exit code (Something.framework)
Trash DD Content; rm -rf /Users/dx/Library/Developer/Xcode/DerivedData/*
Restart XCode
Build Phases => Link Binary With Libraries
Something.framework,
Set embed value in General => Something.framework => EMBED
Do not embed
Press Cmd+B (Build Project)
Hopefully Built Successful
In my experience, the reason that caused this problem was I wrongly reset the Keychain Access to default, so I lost my development certificate.
How did I solve this?
I cleaned my Apple Development Certificate from Keychain Access
I cleaned my Apple Development private key from Keychain Access
Then I got the new error : Revoke certificate
Your account already has an Apple Development signing certificate for this machine, but its private key is not installed in your keychain. Xcode can create a new one after revoking your existing certificate.
Go to Xcode Preference -> Accounts Tab -> Fine the team name under the Apple ID -> Double Click it -> Click the + button at the bottom left of box -> Select App Development
In the team drop-down of the target, select "None"
Re-select the correct development team
Clean the project by shift+cmd+k
Rebuild the project cmd+b
I, too, saw this error after adding a mixture of .jpg and .png images to the art.scnassets folder, making code changes, and removing those changes via Xcode's Source Control > Discard All Changes... menu.
I tried the other fixes in this thread but, ultimately, I had to delete the added .jpg/.png files, clean the project, and rebuild the project to eliminate the errors. I then readded the original .jpg/.png files and I'm now rebuilding the code without issue.
For me I had to go to keychain, select the "login" keychain, double click on the iOS Developer:myname key, click the access control tab and switch the radio button to Allow all applications to access this item.
This problem was caused by building my project in the Release schema. It can be caused by other things as well. Try to switch the build schema by going in xCode to
Product > Scheme > Edit Scheme. In the "Run" Section located on the left, switch the "Build Configuration" to "Debug". I hope this will help.
None of the above solutions worked for me. After some guess work, I tried (Xcode v10.2.1 cocoapods v1.7.1)
pod deintegrate
followed by
pod install
Then:
Opened the workspace in Xcode
Cleaned build folder
Build the project
No build errors.
My Problem was solved
Check Automatically manage signing on Target MyProject and Add Team.
Check Automatically manage signing on Target MyProjectTest and Add Team.
Product -> Clean Build Folder -> Build again or try to run on device.
The problem occurs when you have the wrong/different team on MyProject and MyProjectTest.
Reconnecting your phone prior to rebuilding may also assist with fixing this issue.
It works for me by delete all the apple developer Certification in the keychain. and generate it in the Xcode.
I was experiencing this issue due to the misconfiguration of my Apple Worldwide Developer Relations Certification Authority certificate.
I resolved issue by switching from "Alway Trust" to "Use System Defaults"
Step by Step:
Open KeyChain
Click on "login" keychain (make sure it's unlock - if it's locked Right Click on it and choose "Unlock KeyChain")
Click on Certificates and locate Apple Worldwide Developer Relations Certification Authority certificate
Right click on it and choose Get info
Expand Trust section and change settings to Use System Defaults as per below screenshot
This issue can also occur when upgrade from XCODE 11.x to 12.0. After installation of new version of XCODE, restart system to overcome this issue.
I fixed this issue only by renaming Resources folder (not group) to any other names such as Resource, Resources123, etc.
None of other answers worked. This is what I have done:
deleted my certificate from keychain;
opened Xcode it rebuild certificate;
ran app on device successfully.
in my case it was a corrupted storyboard file
After i copied two .aiff files in a .scnassets group, this error
occured. Deletion of the files and a "Clean Build Folder" solves the problem in my case.
Not sure if this will help anyone - but make sure you have Find Implicit Dependencies checked off. Sometimes this can lead to your project "losing track" of where to look for certain things.
Once you do this, I suggest then also cleaning your project and rebuilding.
My app runs on devices and simulators. The app archives with no errors. When I try to export I get the following error:
The log file IDEDistribution.critical.log contains the following:
2017-07-07 07:40:03 +0000 [MT] Failed to generate distribution items with error: Error Domain=IDEDistributionErrorDomain Code=12 "The archive contains nothing that can be signed." UserInfo={NSLocalizedDescription=The archive contains nothing that can be signed., NSLocalizedRecoverySuggestion=Verify that your build process has compiled binaries and copied in bundled resources.}
2017-07-07 07:40:03 +0000 [MT] Presenting: Error Domain=IDEDistributionErrorDomain Code=12 "The archive contains nothing that can be signed." UserInfo={NSLocalizedDescription=The archive contains nothing that can be signed., NSLocalizedRecoverySuggestion=Verify that your build process has compiled binaries and copied in bundled resources.}
The contents of the .xcarchive:
The .app also contains all the usual stuff.
I am sure there may be more information needed. Please ask and I will provide what I can.
What fixed my issue was including arm64 in the app architecture,
In your Target -> Build Settings search for:
VALID_ARCHS and make sure arm64 is included.
search for Excluded Architectures and make sure arm64 is NOT mentioned there.
Change the archive destination directory to a location on the local SSD (and not an external HDD).
I have not had this problem again after I did this and I recall having started running into the problem after I started trying to free up space on my mac.
At last! There may have been other issues too, but only after I changed the scheme container was I able to export. And I knew it had something to do with CocoaPods.
Before pod install your scheme may look something like this:
There are no other container options.
After pod install it will look like this:
Once I selected the Workspace container I started seeing a difference in the build and consequently the export worked.
For me helped relaunching an Xcode. I think the problem is because all archives stored in a separate HDD and it was something with the access to it by Xcode.
I had similar error when I was resolving error occurred after shifting from Intel based mac to M1 based mac for a ReactNative based project. For resolving some fixes, I had to exclude the arm64 in the project build settings, but I also excluded it in the target. I removed the "arm64" from all schemes of the excluded targets of Excluded Architectures of the project target and rebuilt the code. It worked.
So I already was able to build the .bar file, but now I want to build the .bar file to be sent to the store with the package and signing.
So far I've tried this.
bbwp C:\xampp\htdocs\maddash\packaged\maddash.zip -g (password) -b 1.0.0 -o C:\xampp\htdocs\maddash\packaged\
and my error is..
failed to find signing key file
Did you register your keys from RIM and put them in the default location (%HOMEPATH%\Local Settings\Application Data\Research In Motion for Windows)
Did you update your SDK? Then check your keys in bbwp\bin and rename sigtool to author and move your file to the default location.
If not sufficient, try installing the native IDE and use the UI for managing the keys in the preferences
My personal opinion about this problem.
First. If you have your signing key, great for you, because BB changed the system of signing apps. (Now they use BBtokenID, related with your BBID and, in this moment, the webworks framework is the only one that doesn't support this tokens) (Come on, Hip, Hip, Hurrah! :P).
According to your command, one comment
bbwp C:\xampp\htdocs\maddash\packaged\maddash.zip -g (password) -b 1.0.0 -o C:\xampp\htdocs\maddash\packaged\
In the first paramenter yoy must add the FOLDER of your source code, not your zipped code.
If you have your keys where it corresponds, it will generate a bar file signed.
NOW, you must package it in a zip file. If you need more help with that, tell me :)
I'm working with Xcode 4.1 build 4B110f trying to get my iOS app ready for upload. It passes the Product|Archive step with no errors, asking twice for permission to sign something. But when I try a validate of the archive from the Organizer, it fails:
### Codesigning '/Users/uqrchern/Library/MobileDevice/Provisioning Profiles/70D2381D-3733-4F5D-88B2-4729572C2864.mobileprovision' with 'iPhone Distribution: Ron Chernich'
+ /usr/bin/codesign --force --preserve-metadata --sign iPhone Distribution: Ron Chernich --resource-rules=/var/folders/ul/ula1AHKnGpqQ9ftDnUL-l++++TM/-Tmp-/rybczU3EBd/Payload/ABRA-D.app/ResourceRules.plist --entitlements /var/folders/ul/ula1AHKnGpqQ9ftDnUL-l++++TM/-Tmp-/rybczU3EBd/entitlements_plistrZ1Vwko6 /var/folders/ul/ula1AHKnGpqQ9ftDnUL-l++++TM/-Tmp-/rybczU3EBd/Payload/ABRA-D.app
Program /usr/bin/codesign returned 1 : [/var/folders/ul/ula1AHKnGpqQ9ftDnUL-l++++TM/-Tmp-/rybczU3EBd/Payload/ABRA-D.app: replacing existing signature
/var/folders/ul/ula1AHKnGpqQ9ftDnUL-l++++TM/-Tmp-/rybczU3EBd/Payload/ABRA-D.app: object file format invalid or unsuitable
]
error: codesign failed with error 1
I've looked at all the similar problems and solutions (some of which make no sense whatever, or apply to really old versions of the tools). None have made the slightest difference.
I've also checked 3 times that verify is using the "production" certificate, as is the codesign step that produces the archive. I've even turned the above output into a schell script so I could try all certificates manually: same result every time.
Maybe the .app file being signed really is unsuitable?
Incidentally, codesign has no version flag, but the man page is dated June 1 2006. The binary has a file date of Nov 20 2010.
UPDATE (next day):
Researching the problem further found an obscure reference saying that codesign needs the following environment var set:
CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
Using the output from a failed Validate run, I created a shell script which exported this var just before the failing codesign --force step and viola! The codesign works.
But this does not really help me prepare my code for upload. Is there a way to include this into the script run by the Organizer Validate button??
A LITTLE LATER STILL, THE SOLUTION! :
Under the theory there is a script someplace which generates all the commands run during an Organizer Validate... run, I did some digging with grep and find. The script indeed exists and it's name is:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
It's just Perl and the fix is to add the required environment var to the associative array %ENV right at the start, say at line 72:
$ENV{CODESIGN_ALLOCATE} = '/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate';
This totally fixes the problem. I've no idea where all the other posters on the web who think they fixed it by combinations of deleting certificates, building clean, shutting down and restarting Xcode, etc, etc are coming from. I'll just quietly assert that this fix favors science over superstition and works for me under Xcode 4.1 Build 4B110f and its associated PackageApplication script, running under Snow Leopard 10.6.8 with Perl 5.10.0
Just so that this can be taken off the unanswered list. Like you said, you need to add CODESIGN_ALLOCATE to the $ENV array:
$ENV{CODESIGN_ALLOCATE} = '/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate';
If everyone is in agreement here, I think this question can finally be closed.
When using a more recent version of Xcode, the default location is:
$ENV{CODESIGN_ALLOCATE} = '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate';
In case you get this on a recent version of Xcode, what you actually want is, in the shell:
export CODESIGN_ALLOCATE=`xcode-select -print-path`/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
which will use the codesign_allocate from the version of Xcode you are using.
You can update the version of Xcode the command line tools use by running xcode-select -switch
I had this workaround in place for a long time, but after upgrading to Xcode 4.3 with iOS 5.1 SDK, my signing script (which calls codesign) stopped working with a cannot find code object on disk error:
output/Enterprise/Payload/MyProduct.app/MyProduct: replacing invalid existing signature
output/Enterprise/Payload/MyProduct.app/MyProduct: cannot find code object on disk
Code signing failed, not creating .ipa file
It seems this workaround isn't necessary for binaries built with Xcode 4.3. To fix, I updated my bash script to check if the location exists before exporting it:
# Only export the environment variable if the location exists,
# otherwise it breaks the signing process!
if [ -f "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate" ]
then
echo Export environment variable for codesign_allocate location
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
fi