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.
Related
I'm working on a SFML app for macOS with the latest Xcode version.
I got a "Command CodeSign failed with a nonzero exit code" error when it tries to sign the SFML frameworks. I added these under "Link Binary with Libraries" and "Copy Files" in Target, under Build Phases. Before, I was working with my local frameworks under /Library/Frameworks, and it was working very well.
Now I need to create an archive .app.
I've tried a lot of things seen on other posts here (like lock and unlock my keychains), but nothing worked. Still got that error.
My SFML Frameworks in "Link Binary with Libraries"
/Users/lounesksouri/Library/Developer/Xcode/DerivedData/Squadro-gqwjbvsooypqaifxxyzhdrahkdpo/Build/Intermediates.noindex/ArchiveIntermediates/Squadro/InstallationBuildProductsLocation/Applications/Squadro.app/Contents/Frameworks/sfml-system.framework/Versions/A: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code
Ok, I solved my problem, after long hours.
It's a lot more simple to use the script already present in Build Phases tab, generated if you use the SFML App Xcode template (see here the original script). I had tried it at first, but it didn't work so I let it down.
But, in this script, the first three lines are not the good ones, for a normal SFML installation on macOS. We need to modify these lines with the good paths to the Frameworks and lib folders, as follows :
SFML_DEPENDENCIES_INSTALL_PREFIX="/Library/Frameworks"
CMAKE_INSTALL_FRAMEWORK_PREFIX="/Library/Frameworks"
CMAKE_INSTALL_LIB_PREFIX="/usr/local/lib"
FRAMEWORKS_FULL_PATH="$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/"
Secondly, there is still the code signing problem : the archive will created but we will get an error if we start the .app. The solution to this problem is to check Disable Library Validation under Target/Signing & Capabilities to allow the application to load plug-ins or frameworks signed by other developers.
Finally, if we create the archive and launch the application, everything goes normally, as planned.
I faced this problem with the new update of Xcode. I was reading your discussion, and did some accidental modifications. I am definetely not an expert but what I did fixed the problem so I did not receive tgis error anymore. So I added the sfml libraries (5 libraries), whose paths are written in build settings -> framework swarch paths. And this adding automatically added them in Embedded Frameworks under the Build phases section. What I did is unchecking the checkboxes of all 5 libraries "Code sign On copy". Thank you guys for giving me the path for "solving" the problem :))))
For the Code-signing issue:
Open a Terminal,
Go to the Framework folder (cd /Library/Frameworks) and sing them.
choose your identity
security find-identity -vp codesigning
sign them Frameworks!
codesign -s AD90FAFAFAFAFAFAFAF-YOURHASH-9D6 ogg.framework
codesign ... all the others
run and enjoy!
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.
Edit: Turns out this was not a codesigning issue, so I'm updating to help anyone who runs into the same problem.
After updating a MonoMac app to Xamarin.Mac, if I changed the name of the app, I would get the message "You can't open the application "XXXXX" because it may be damaged or incomplete." It looks like it could be a codesigning issue because when I would run codesign --verify I would get code object is not signed at all.
Original question:
I recently updated a MonoMac app to Xamarin.Mac. In the process, something in the codesigning step seems to have changed. Specifically, now when I rename the app bundle, I get codesigning signature errors, both from the GUI and from the command line tools. It seems that if the app bundle does not match CFBundleName, the signature isn't valid.
For example, if I run codesign --verify --deep -vvvv Program.app (where Program matches the CFBundleName, I get
Program.app: valid on disk
Program.app: satisfies its Designated Requirement
However if I change the name to Program2.app and run codesign --verify --deep -vvvv Program2.app, I get:
Program2.app: code object is not signed at all
Move it back, and I get a successful signature again.
From looking at the MonoMac app vs. the Xamarin.Mac app, there are a few differences:
archived-expanded-entitlements.xcent is now placed in Contents/Resources
Info.plist gets compiled to some binary-ish version.
Contents/MonoBundle now includes libMonoPosixHelper.dylib, which apparently needs signing.
PkgInfo is now included in Contents, with contents APPL????
Why do the codesigning tools care about the name of the app all of a sudden? How can I make it not care about the name?
It turns out that the problem was a change in the update from MonoMac to Xamarin.Mac that somehow set it to look for the executable to be named the same as the app bundle, so if you changed Program.app to Program2.app, OS X would look to run Contents/MacOS/Program2 instead of Contents/MacOS/Program. I'm still not sure why the MonoMac version worked when renamed, but clearly it had some other pointer to the correct executable file.
The solution for Xamarin.Mac is to add
<key>CFBundleExecutable</key>
<string>[Original app name]</string>
to Info.plist. This tells OS X where to look for the executable, and allows you to rename the app without issue.
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
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.