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
Related
We are currently trying to have our app verified in order to distribute it outside of the app store. We are including OpenSceneGraph libraries as well as Qt frameworks in the app bundle.
This is how we did it so far:
Signed executable in Contents/MacOS folder
Signed libraries and Qt frameworks
Signed App.app folder
zipped .app and submitted for Notarization
The executable, libraries and frameworks signing is done manually with the codesign command, and to sign the whole .app we do the following:
codesign --force --verify --verbose=3 --options runtime --timestamp --entitlements App.entitlements -s "Developer ID Application: Our Dev Id" App.app
When we send the zipped .app to be notarized we usually get a quick reply informing us that the notarization was successful, but if we try to run
spctl --verbose --assess --type execute -v App.app
we get the following error:
App.app: rejected (unsealed contents present in the root directory of an embedded framework)
Also inspecting the json file with the notarization output we notice the same error, but it is marked as a warning and checking it with codesign no error is returned.
After a bit of digging we realized that the issue is related to the Qt frameworks: as a counterproof, we tried to submit the same app without the Qt frameworks and this time when the bundle was successfully notarized spctl accepted it too.
Consequently, we eliminated the all symlinks in the root directory, moved the .prl files into the Resources/ folder, and created an alias to A/ in the Versions/ subfolder as suggested in several forum posts, but we have not been able to have spctl accept our bundle with the Qt frameworks. Now at the root of each framework there is just the Versions folder and nothing else (we checked with ls-lha to be sure)
What are we missing in this? Is there a way to at least get some hint on where is the unsealed content which is upsetting the verification tool?
Thank you in advance
In the end, turns out macdeployqt was the way to go, because it automatically arranges the Frameworks in a way that makes it possible to sign the bundle with no error.
Our problem with some framework not being added by macdeployqt disappeared when we upgraded from Qt 5.12.2 to Qt 5.14.1
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.
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.
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.
I am porting a .NET application to OS X using the Mono Framework. The application works fine, and we have everything done except for packaging. I am packaging a standalone Mono build inside the bundle to avoid dependencies, and using this tool for the job: https://github.com/OutOfOrder/MonoKickstart
The bundle structure we are using is like this:
OurApp.app
\-Contents
+-Info.plist
+-MacOS
| +-osx - native libraries for osx
| +-mono - mono config files
| \ ... - the OS X kickstart binaries, the .exe file, C# .dlls
\-Resources/
\-icon.icns
The bundle runs fine when OS X's Gatekeeper functionality is set off, but when trying to sign it to get it run always, I run into problems...
$ codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --deep --verbose OurApp.app
OurApp.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: OurApp.app/Contents/MacOS/mono/4.0
All right, I'll remove the mono directory temporarily just to see if it proceeds then:
$ codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --deep --verbose OurApp.app
OurApp.app: signed bundle with Mach-O universal (i386) [org.ourcompany.ourapp]
Success! Or so do I think, but when I'll try to run the app, it still says it's still blocked by Gatekeeper. And when I run
spctl -a -v OurApp.app
OurApp.app/: rejected
So what gives? It says it signed the bundle, and using the --deep parameter, it should've signed all the libraries and such, if I understood right. What should I do to make this work?
Update:
Tried to sign the files one by one with this.
codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --verbose OurAppExecutable.bin
But it refused to do it, because of the "subcomponents" (Even if I'm not using --deep).
I finally got it to sign it by moving everything else but the actual binary file to Resources folder, and then signing the binary file, and then the app bundle.
But yet, it says:
spctl -a -v OurApp.app
OurApp.app/: rejected
source=No Matching Rule
Any further insights?
I'm not sure if --deep is supposed to work or not, but it's not what we use in Xamarin Studio when codesigning Xamarin.Mac projects. What we do is codesign each native library individually and then codesign the app bundle itself.
Hope that helps.
Update: This may be the problem:
OurApp.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: OurApp.app/Contents/MacOS/mono/4.0
The problem might be that MonoKickStart is not generating correct Mac executables?
I got this to work afterwards. The trick was to keep just the one and only executable file in the MacOS dir, and have everything else in the Resources dir. This way we didn't need to sign all the other things.
Another blunder - not the source of this problem, but of an another one - was that we were trying to sign it with a wrong kind of certificate. "3rd Party Mac Developer Application" is apparently used for App Store submissions. The name is kind of misleading, so it's easy to mess that up. More info: Difference between “Mac Developer” and “3rd Party Mac Developer Application”