I've built an App in Xcode in release mode. Is signed with valid Developer ID certificate. And the app launches fine on some MacBooks.
But on another launch fails with error
The application %name% can't be opened.
Then I try to launch it from terminal with open command it says
LSOpenURLsWithRole() failed with error -54 for the file /Applications/Gaetano Lunches.app.
And then I try to launch directly the binary file from package contents
it says
-bash: /Applications/Gaetano Lunches.app/Contents/MacOS/Gaetano Lunches: Operation not permitted
On all MacBooks app installation from Anywhere is allowed. spctl-master is disabled. Permissions for files are correct. But the app cannot be launched.
I don't know how you are building your app, but if LSOpenURLsWithRole is returning permError = -54, this means you have a permission error on opening a file. This can mean a lot of things, but building an app in release mode is no longer what Apple recommends for you to do. Apple prefers that you use Archive and then you export the app in Organizer to be used by your users. By using this work flow, normally you can do everything using the Xcode defaults for building an app. If you don't, then you need to be more careful with the settings you choose for building in release mode.
For a quick and dirty approach, I would try the following:
1) Open the terminal
2) Type: chmod +x "/Applications/Gaetano Lunches.app/Contents/MacOS/Gaetano Lunches"
3) Try to launch your app and see if it helps. If it helps, there is something messed up with your build settings, which is failing to change the file permissions somewhere for your executable to have the right permissions to be launched.
Another thing you could try is see whether your app was blacklisted by Gatekeeper, because somehow it determined your app is doing suspicious things on your own system. If that is the case, then you can try this to see what gatekeeper is assessing:
spctl -a "/Applications/Gaetano Lunches.app"
If for some weird reason you app is being blacklisted by Gatekeeper, you can always add your app manually and whitelist it for Gatekeeper:
spctl --add "/Applications/Gaetano Lunches.app"
If all fails, you can try to reset the whole database, but you will need super user access:
sudo spctl --reset-default
However, I think these are just quick fixes, and if you keep needing this is because your build settings in Xcode must be adjusted. More on that, if any of these solutions work. Let me know about that.
Related
I'm experimenting with building a Windows and Mac OS app using Electron and have hit a snag.
In short, if I try to run the application directly with Electron on Mac OS Big Sur (as opposed to building a Mac app and then running that) I get the following error returned:
[35941:0821/171720.038162:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
I am running directly with Electron using the following in my package.json:
"scripts": {
...
"test": "electron main.js",
...
}
So far the only Mac OS environment I have access to is Big Sur so haven't tried this on earlier versions of Mac OS but from Googling it seems this error may be related to Big Sur's tightened security/sandbox constraints -- but I am guessing about that.
In any case, after some Googling several suggestions indicated trying to run without the app sandbox, i.e. adding this to main.js:
app.commandLine.appendSwitch('no-sandbox');
That's all well and good and works.
However, if I ever want to build and distribute a signed Mac app targeting the Mac App store or a just a signed, sandboxed DMG or PKG installer, then this won't be suitable.
If I remove the above no-sandbox command from main.js and specify the app sandbox in my entitlements plist as shown below the resulting signed app will not run:
<key>com.apple.security.app-sandbox</key>
<true/>
The app tries to open and just closes. I can try running at the command line with open <appname>.app but this throws the following error in the console:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2561, NSUnderlyingError=0x7fd3c9c13db0 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7fd3c9c158e0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 153}}}}}
If I build a signed app with no-sandbox enabled, the app will run just fine on Big Sur using open <appname>.app.
I have tried my best through Google, Stack Overflow, etc to diagnose this but am not getting anywhere. Here's to hoping the Stack Overflow community can provide me the critical clue to solving this.
For further context, I created a new, empty Electron application and followed the Electron Quick Start Guide to the section where it describes creating an empty main.js which technically should allow the Electron app to start -- but it won't. The same error describe above re the GPU gets thrown even without instantiating a BrowserWindow or writing any custom code of my own.
NEW UPDATE: I set these environment variables to true and then tried running the app with npm start:
ELECTRON_ENABLE_LOGGING
ELECTRON_DEBUG_NOTIFICATIONS
ELECTRON_ENABLE_STACK_DUMPING
The result is more detailed error output:
[48836:0823/165857.676747:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48836:0823/165857.676838:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48778:0823/165857.677376:ERROR:gpu_process_host.cc(1003)] GPU process exited unexpectedly: exit_code=5
[48778:0823/165857.677430:WARNING:gpu_process_host.cc(1317)] The GPU process has crashed 1 time(s)
[48850:0823/165857.827224:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48848:0823/165857.827255:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48850:0823/165857.827341:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48848:0823/165857.827358:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48778:0823/165857.827836:ERROR:gpu_process_host.cc(1003)] GPU process exited unexpectedly: exit_code=5
[48778:0823/165857.827875:WARNING:gpu_process_host.cc(1317)] The GPU process has crashed 2 time(s)
... repeats until the GPU processes crashes 9 times ...
[48778:0823/165903.080134:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Haven't had time to do the research as to what ICU refers to but thought I would update with this info.
ANOTHER UPDATE: all this has been done on Mac OS Big Sur which is my main development machine. Trying this on a Windows 10 machine, using the same Electron code, dependencies, etc and things work fine. So the problem is either related to Mac OS Big Sur or a specific local issue on my development machine which I cannot identify. Any suggestions on how to diagnose this will be much appreciated.
ONE MORE UPDATE: Based on a guess, I created a new user on my mac, took the code in there and it ran perfectly. So -- this probably means that I need to find something installed in my profile or some corruption in my own profile/settings that is breaking things. As always, any suggestions appreciated it.
In my case, I got this to work using command line switch, --in-process-gpu, or:
app.commandLine.appendSwitch('in-process-gpu');
There's also an extensive list of Chromium switches here that you can try at:
https://peter.sh/experiments/chromium-command-line-switches/
Yeah, the whole hardened runtime thing is just such an awful, awful mess! Now to figure out the next crash!
So -- partial answer. I think I've found the solution to this error:
GPU process isn't usable. Goodbye.
My development directories are all on a file system accessed via a symbolic link. As soon as I moved the folder for this app to my my home directory (no symlinks involved) I could launch with npm start without needing to enable no-sandbox and without seeing this error or the errors related to icudtl.dat.
I haven't yet determined if the problem described with the error below when launching the packaged app is related/solved:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2561, NSUnderlyingError=0x7fd3c9c13db0 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7fd3c9c158e0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 153}}}}}
That said, it is a big step forward.
I have a similar issue on a linux machine with an electron app. The answer in this github issue helped me.
Using --disable-gpu-sandbox flag with electron apps solved it for me.
The underlying problem seems to be that the Mac OS sandbox is preventing the GPU process to spawn properly.
You can specify a variety of entitlements when packaging your application, but not all entitlements are created equally, especially entitlements that want access to the keychain, secure enclave and TouchID.
If you're specifying a provisioning profile - make sure that all those entitlements are only in the original file, keep your inherited entitlements empty or to the bare minimum. In my case, I had the keychain-access-groups specified in my inherited entitlements which was a painful lesson to learn. Removing it made the builds not crash!
I believe in your case it's likely that you tried to access files outside of the application itself which might have caused the sandbox to prevent opening the GPU processes.
I know the OP reported this against MacOS, but on my Windows 10 VM I used the following instructions to create the electron-quick-start app…
net use T: \\busdata\company\BrianT
T:
cd \Development\Sandbox\electron
"C:\Users\thomasb\AppData\Local\GitHubDesktop\app-2.9.15\resources\app\git\cmd\git.exe" clone https://github.com/electron/electron-quick-start
cd electron-quick-start
npm install && npm start
…and then electron wrote error messages to the console, the same errors as those reported by the OP:
[5796:1025/121431.238:ERROR:gpu_process_host.cc(969)] GPU process launch failed: error_code=18
[5796:1025/121431.328:FATAL:gpu_data_manager_impl_private.cc(441)] GPU process isn't usable. Goodbye.
An earlier answer mentioned symbolic links, and to investigate that further I xcopied the entire electron-quick-start folder down from T: (a remapped network folder) to C: (my local disk).
When I then ran npm start in the folder that I'd copied down to C: there was no error.
Looks like electron is being fussy about where the source files live.
I had the same Issue when running the files off of a server such as a nas, but moving files to local storage solved the issue.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 months ago.
Improve this question
I installed macOS v11 (Big Sur) yesterday and since then I am not able to run some old application. This is the message I get:
You do not have permission to open the application
I think this application is from an unknown developer.
I tried different methods that were working in macOS v10.15 (Catalina) like:
spctl --master-disable
Or I tried also to disable SIP and AMFI.
I've also tried:
sudo xattr -rd com.apple.quarantine /Applications/my_app.app
If I run the application from the terminal, this is the text version of the error I get:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2508, NSUnderlyingError=0x7fcb24c13ec0 {Error Domain=RBSRequestErrorDomain Code=5 "Launched process exited during launch." UserInfo={NSLocalizedFailureReason=Launched process exited during launch.}}}
Also tried to disable encryption and run:
csrutil authenticated-root disable
This is the error window:
I had this problem with the error "Termination Reason: Namespace CODESIGNING, Code 0x1" and I managed to open the application after I signed it again on that machine, with the command:
codesign --force --deep --sign - /Applications/AppName.app
No other solution worked for me.
It seems to be a permissions issue on one of the files deep in the .app that you moved to the applications directory.
Open Terminal or iTerm and type "chmod -R 755 " and drag the .app into the window, which will bring the full path into Terminal or iTerm.
It will look like this:
chmod -R 755 Path\ to\ app\ file.app
Press return
Then, you can open the app file normally, but it will fail because gatekeeper won't be able to verify the file. From there, go into your "Security and Privacy" in "System Preferences" and then click to allow the app to open.
The problem in my case it was related to a Big Sur problem where UPX compressed binaries are not recognised properly, so they were not executed with a permission error.
There is some more information here: UPX compressed application fails to start on latest macOS release: Big Sur 11.01 #424
So the solution is to unpack the binary with UPX and run it normally.
Install upx with Homebrew (executable brew):
brew install upx
Now run this command:
sudo upx -d /Applications/my_app.app/Contents/MacOS/my_app
(Please note you have to specify the full binary path.)
You should use the path of your binary instead of "/Applications/my_app.app/Contents/MacOS/my_app"
Then run the application normally.
I found a solution:
You need to resign the app,
(install Xcode tools, if necessary):
xcode-select --install
sudo codesign --force --deep --sign - /Applications/YourAppName.app
Move the app to quarantine:
sudo xattr -d -r com.apple.quarantine /Applications/YourAppName.app
Go to /Applications/YourAppName.app/Contents/MacOs and make the file inside executable:
sudo chmod +x Script_name
That worked for me and the app launched.
This answer will only apply to a specific set of applications
I had this issue with a universal binary (Terminal) that I duplicated and explicitly set in the info "Open using Rosetta" to run x86 tools like Homebrew. After updating to 11.0.1 from 11.0.0, the x86 version of the terminal stopped working with the above error.
I simply had to delete the duplicate, created another duplicate of the terminal and enabled Rosetta again.
First figure out that your application signature is valid:
From Apple's official website:
All apps in the App Store are signed by Apple to ensure they have not been
misused or tampered with. Apple signs any app that comes with Apple
devices.
To check this out, you can type the following in your terminal (the path of Folx.app is just for an example and you should replace it with your desired app):
pkgutil --check-signature /Applications/Folx.app
if you get an "invalid signature" responce, something like this:
Then your app maybe was installed in some hacky way! And now your easiest approach is to uninstall the app and reinstall it again.
Otherwise, you will have plenty of hard time to enjoy (😎) with that app, Xcode, and signature stuff...
You have to run SUDO xattr -d com.apple.quarantine <app>. It's important that you don't forget sudo or it won't work.
This is the only solution that worked in my case.
Download macOS-GateKeeper-Helper.
Open GateKeeper_Helper.command by double-clicking on it (if it says untrusted developer, go ahead and run it from Settings - Security & Privacy - General - Open Anyway)
Select Option 4 (Remove app from GateKeeper quarantine)
Drag and drop the app file from the Applications folder, hit the Return key, and enter your password
You will see a message like “App removed from quarantine”. That’s it. Try to open the app as usual.
If you are uploading an Xcode app to GitHub releases, make sure to compress it first on your computer, don't let GitHub compress it.
For my team, this turned out to be a problem with Git adding CRLF to the Entitlements.plist file.
Once I fixed the .gitattributes file to only use LF with p-list files, I built a new app and had it codesigned and it worked--no aborts. I also had to make sure Jenkins wiped the workspace since it didn't seem to fix the file at first.
I encountered this issue when sending to a colleague for testing a Mac app that I developed. He tried some of the suggestions on this forum, but they didn't seem to work (and we're both on Intel, so the Rosetta tips didn't apply).
What ultimately worked for me was creating a blank disk image, and then adding the .app file to the image and then sending him the disk image. It seems like the problem comes up when the .app file is compressed, and adding the file to a disk image first seems to help prevent the issue.
For my macOS desktop application's UI test target, I need to be able to run command line tools (specifically git) to verify some application actions, but I get an error that it cannot be run in the app sandbox.
I never explicitly enabled sandboxing for either my app or for the test target, so I'm having trouble figuring out how to turn it off. There is no entitlements file, and I can't find any target settings that seem to relate to sandboxing.
So is it possible to disable sandboxing for a UI test target? I know workarounds could include copying git into the bundle, or having the user explicitly select the tool, but neither of those seems really desirable.
Update: I tried copying git into the test bundle to run from there, but still got the same error.
Update 2: You can turn off sandboxing for the test bundle, but the test runner which Xcode builds automatically is still sandboxed (and unable to load an unsigned bundle), and AFAICT there is no way to change how the runner is built. Am I wrong?
Create .entitlements file with
<key>com.apple.security.app-sandbox</key>
<false/>
and specify CODE_SIGN_ENTITLEMENTS for your UI Tests bundle(via xcconfig or Build Settings -> Signing). Xcode will use value for this entitlement for test runner application.
The fix that worked for me was to copy git into the bundle, making sure that it's code signed during the build. Then it can be run from the sandboxed test runner.
The catch is that the binary at /usr/bin/git is not the real git tool, it's a placeholder that forwards to xcrun which finds your active Xcode installation and runs the copy of git inside that app bundle, and you can't do any of that inside the sandbox. So you have to copy it directly out of Xcode.
Like this:
Add git from Xcode by navigating to Xcode.app/Contents/Developer/usr/bin/git and setting the Location popup to "Relative to Developer Directory"
Add a Copy Files build phase to your UI Test target to copy git into the Executables directory (if you put it elsewhere it won't get code signed as an executable)
Make sure "Code Sign on Copy" is checked in that build phase (it's the default)
At runtime, find git using Bundle(identifier: YourTestBundleID).url(forAuxiliaryExecutable: "git")
So my problem is that on pure swift project (almost :-) ) with test written also in Swift I got this every build. Build is started via Fastlane 1.63. :
▸ DTServiceHub: Instruments wants permission to analyze other processes. Please enter an administrator username and password to allow this.
▸ Username (jenkins): Password:
▸ Failed to authorize rights (0x1) with status: -60007.
Problem occurs when new command-line-tools and Xcode 7.3 was installed on MacPro with OSX Server. Objective-C project works every time. I've done what was suggested in those threads, didn't work:
Remove the authorization prompt from command line instruments (Under mavericks)
Is there a way to remove the authorization prompt from command-line instances of Instruments (XCode)? and in all other places that I could find. I have no idea how to fix it.
I just experienced a similar problem, triggered by Fastlane scan command to execute tests.
Following the discussion on this issue and this Apple Support discussion I managed to solve it by enabling "Developer Mode" on my CI machine.
$ DevToolsSecurity -status
Developer mode is currently disabled.
$ DevToolsSecurity -enable
Developer mode is now enabled.
I've got the same problem with Xcode 7.3. I wasn't admin on my Mac (I work on a company network) so the network manager gave me the admin rights and it works... I don't know why :)
I develop a Mac app with Qt5, so outside Xcode. I want GateKeeper to allow my app to run on clients' computers rather than issuing the "Can't be opened because the identity of the developer cannot be confirmed" warning.
I have successfully digitally signed the app but GateKeeper still comes with this complaint. I have an Apple developer certificate (I am the Team Agent) and my keychain says it is valid. I also have installed two Apple root certificates.
I use the command line utility codesign to digitally sign all the binaries inside the app folder and in addition I digitally sign the app folder itself. In all cases the response of codesign is informative and displays no error. With codesign I can check that indeed all the binaries are signed, running
$ codesign --verify --deep --verbose=2 MyApp.app
shows that all binaries are validated. And in addition it reports:
MyApp.app: valid on disk
MyApp.app: satisfies its Designated Requirement
Running:
$ codesign -v --verbose=4 --display MyApp.app
gives
Executable=/Users/xxx/trunk/yyy/deploy/release/MyApp.app/Contents/MacOS/MyApp
Identifier=aaaa.MyApp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=12461 flags=0x0(none) hashes=616+3 location=embedded
Hash type=sha1 size=20
CDHash=d1c12c783dac0e8d9a2b749fb896b11558cec8b6
Signature size=8532
Authority=Developer ID Application: XXXXX
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 jul. 2015 12;04:40
Info.plist entries=8
TeamIdentifier=YYYYY
Sealed Resources version=2 rules=12 files=10
Internal requirements count=1 size=180
which seems OK.
Running
$ spctl -a -t exec -vv MyApp.app
on all binaries gives as result
MyApp.app: accepted
source=Developer ID
origin=Developer ID Application: XXXX
which also seems OK
Running the XCode command line tool check-signature
on the app or on the binaries inside the app folder:
$ ./check-signature /Users/xxx/trunk/yyy/release/MyApp.app
gives as result
(c) 2014 Apple Inc. All rights reserved.
YES
which in all cases is the desired result.
But GateKeeper still does not accept the app and complains about the fact that the developer cannot be confirmed.
[added by author on Friday July 17, 2015]
I think I have found the problem. I do not know whether it is a feature or an OSX bug. I was helped a lot by stackoverflow question 19551298.
Whenever a file is downloaded from the internet it gets an extended file attribute com.apple.quarantine associated with it. When double-clicking on this downloaded file in Finder, GateKeeper has two possibilities:
When the file is not signed it issues the "Unidentified developer etc" message
When the file is digitally signed it issues the "Developer cannot be confirmed etc" message
In both cases the MessageBox has only one button, an OK button. When this button is clicked nothing happens, apart from the MessageBox closing.
If the extended attribute is deleted (xattr -d) the applications runs, signed or not.
The behavior is different when the applications is started by right-mouse-button-clicking in Finder on the app and then click on the "open" menu action. Again one of the two messageboxes is shown, but now with an extra button to allow the user to open the app anyway. Again the only difference between signed and not signed is the "Unidentified" or the "Not confirmed" message. I do not expect my customers to be able to tell the differende. As a result signing the app is an exercise in futility.
On the basis of the Apple Support Documentation I expected another, much nicer behavior of GateKeeper when double clicking a downloaded app (perhaps the documentation is outdated, or I misread it):
if the app is signed GateKeeper should show a MessageBox with "Downloaded from the internet etc" and a button with "Proceed anyway?"
if the app is not signed a MessageBox with a single OK button and a text "Unidentified developer etc.."
Sorry for answering my own question, but I see no other way as editing the original question would lead to spaghetti text.
I finally solved my problem. First the credit: (i) The answer to my other stackoverflow question was very useful and (ii) I got very good (paid) advice from an official Apple developer, by filing a so-called Technical Support Incident (TSI).
On the basis of all this I am now able to give here a very concise recipe of how getting your Mac app successfully treated by GateKeeper. After detailing the recipe I will show what my original mistake was.
Goal: After having developed a Mac app outside Xcode to have GateKeeper issuing the warning "Downloaded from the Internet ..." with three buttons, one of which is "open".
Failure: When GateKeeper issues a warning with either the text ".. unidentified developer.." or the text ".. unconfirmed developer .. " with - in both cases - a messagebox with a single OK button.
Getting your app GateKeeper-ready involves three steps:
Make your app standalone with no unacceptable external dependencies. The only acceptable external dependences are system libraries. All other dependencies should have been copied to your MyApp.app folder. GateKeeper rejects any app that has non-system external dependencies
Binaries should not be located at illegal positions inside the MyApp.app folder. Libraries go into MyApp/Contents/Frameworks and the executable goes into MyApp/Contents/MacOS
All binaries inside MyApp should be digitally signed. Then the MyApp.app folder should be signed. For this signing an Apple "Developer ID Application ..." certificate is necessary
Our recipe is automatic. All the work is done by one script. In case of Qt Creator we use a qmake script where we access the system shell through the $$system command. When using either of the (Xcode) system commands codesign, spctl or check-signature we assume you have redirected stderr to stdout as outlined in answer to question . Otherwise you will not be able to catch the system response when running these utilities. In the following we will not explicitly show this redirection.
HERE IS OUR RECIPE
A. Making the app stand-alone:
copy (with a script) all the needed binaries to the MyApp.folder
run (with a script) install_name_tool -change and install_name_tool -id such that all dependences inside the app are of the relative type #executable_path/../MacOS.. or #executable_path/../Frameworks
run (with a script) otool -L on all binaries inside the MyApp.app folder and flag any illegal dependence, like "#rpath..." or absolute file paths not being system paths. Note that otool -L is not guaranteed to find all dependencies. Plugins are often beyond the horizon of otool. That is why you need the next check.
start a terminal at the location "MyApp.app/Contents/MacOS". Run export DYLD_PRINT_LIBRARIES=1. Then run inside the same terminal window ./MyApp. Your terminal will fill up with over hundred loaded libraries. Check this list again for forbidden libraries (libraries present on your computer, but not on the computer of your customers).
proof of the pudding is in the eating. We use the MacInCloud virtual machines and check whether or not our app runs there. Alternative solution could be the Mac of a relative who is not a developer. Or you could also create a new user ("test") on your own Mac and copy the app to its Download (or Desktop folder, or ...). In the latter case you must temporarily rename the root folder of your IDE as otherwise the user "test" will find the missing binaries there.
B Signing the app
Signing: With our script we run codesign --force --verify --verbose --sign \"Developer ID Application: ....\" \"/path/to/binary\" on all the binaries in the app and then on the app folder itself. In each case the system response is caught. It should contain in each case the string "signed Mach-O thin".
Verification: Run (with a script) command codesign --verify --verbose \"/path/to/binary\" on each binary in your app and on the app itself and catch the system response. It should in each case contain the strings "valid on disk" and "satisfies its Designated Requirement".
GateKeeper check: Run (with a script) spctl -a -t exec -vv /path/to/binary\" on each binary and on the app folder itself. The system response is caught. It should contain in all cases the string "accepted source".
check-signature: Run (with a script) check-signature \"/path/to/banary\" on each binary and on the app folder itself. The system response is caught. It should contain the string "YES" in each case.
C External check
zip your app into a single zip file. Upload to one of your cloud servers
GateKeepers keeps a long list (typically hundreds of items) of exceptions on its general gate-keeper role. Your app must not be in that list if you want to test GateKeeper. Rather than editing this list a much simpler trick is creating a new user on your Mac. Log in to that user and download the zip file from the Internet cloud server. Finder will automatically uncompress it. Click on it. If GateKeeper tells you that it can open the application but it warns you at the same time that it is downloaded from the Internet, it is time to grab a (white) beer.
Here the desired GateKeeper warning:
My mistake
I did much of the installing and signing without explicitly checking the result for each binary. After that I would use otool -L on a number of binaries but not on all. I missed the fact that upgrading to Qt 5.5 from an earlier Qt version the binary libqminimal.dylib has acquired an extra dependency, viz.: QtDBus. I had not noticed it, but GateKeeper did.
Qt developers might wonder why we not just use macdeployqt for deploying Qt application on a Mac. In the first place we do not like not to use ill-documented black-box utilities. On Internet fora there are quite a number of people reporting issues with macdeployqt. In addition the Qt libraries can have different install locations (as reported by otool-L) when comparing different Qt versions. When we have a new Qt version our script will immediately start to yell about forbidden dependencies. In this way we get information about what has changed in this new version.
adlag's question and self-answer was invaluable in helping me overcome the same issue. However, as good as his recipe is, some statements are not quite right, so I'd like to offer a few additional points.
It's not necessary to replace #rpath entries in your binaries and dynamic libraries with #executable_path statements. #rpath statements are fine so long as the actual rpath entries embedded in the binaries are not absolute. You can find plenty of valid Qt app bundles that use rpath. You can make it work doing what adlag said, but you may be making work for yourself.
See jil's comment above for how to use otool -l $file | grep -A2 LC_RPATH and install_name_tool -delete_rpath $path $file to inspect and remove the embedded paths in your binaries and libraries
See https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207 for a clear explanation of why GateKeeper complains about paths in your binaries, and how you can see the specific complaint in syslog.
If you have a problem with absolute paths, you should first try to fix your build, rather than use install_name_tool after the fact.
If you're using cmake, this is likely helpful: https://cmake.org/Wiki/CMake_RPATH_handling#Mac_OS_X_and_the_RPATH
Don't run spctl -a -t exec -vv /path/to/binary on dylib files. You will get errors about the resource envelope. This is expected, and not a problem.
In my experience, macdeployqt works fine. I solved the problem by changing my build, such that the absolute paths did not get into the offending dylib file (libquazip). I still used install_name_tool to remove the absolute paths to the Qt installation. I then used macdeployqt to create the bundle, sign the bundle and create the DMG file.
My two bits:
To really verify codesigning, I had to either upload my DMG to a
server and download it using a browser or set the quarantine attribute manually:
APP_PATH="Any.app"
xattr -w com.apple.quarantine '0081;5a37dc6a;Google Chrome;F15F7E1C-F894-4B7D-91B4-E110D11C4858' "$APP_PATH"
xattr -l "$APP_PATH" # You should see the quarantine attribute here
open "$APP_PATH"
If your app is correctly signed, you should see a system dialog with
an "Open" button.
I found the value of the quarantine attribute by looking at another
.app downloaded from the internet. I don't know what the value
means.
I don't really understand why the spctl command says "accepted" even
if the Gatekeeper service denies opening the app.
I had the "unidentified developer" message box because my Qt frameworks were referenced as "#rpath/QtCore.framework". Changing it to "#application_path/../Frameworks/QtCore.framework" using the install_name_tool fixed the issue in my app.
Figured out the problem after lot of tries.
In my case:
The Pop Message - damaged application came due to libraries were missing.
I Had created .app file using QT.
To generate dmg i was using deploymacqt command tool.
deploymacqt tool creates dynamic libraries inside .app, so basically if we codesign before creating dmg, this alter will manipulate code sign.
So the proper fix is.
# Create dmg using
deploymacqt <yourapp.app> -dmg
# Open resulted dmg file, copy <yourapp.app> to different folder(let's say /Documents/<yourapp.app>)
# Codesign the /Documents/<yourapp.app> using
codesign --deep --force --verify --verbose --sign "Developer ID Application: <developerid>" <yourapp.app>
# Verify using
codesign --verify --verbose=4 <yourapp.app>
* you should see something like this
<yourapp.app>: valid on disk
<yourapp.app>: satisfies its Designated Requirement
# Now create again the dmg file using dropdmg(https://c-command.com/dropdmg/) application, download, install dropdmg. set the cofiguration preferences with your developer id certificate in signing option.
# drag and drop <yourapp.app> to dropdmg app, wait for creation of dmg to complete. voila you have now successfully created dmg with proper developer id certification.
# verify resulted dmg again using
codesign --verify --verbose=4 <yourapp.dmg>
# you can also verify with gatekeeper
spctl -a -t exec -vv <yourapp.dmg>
once you are done with these, you will not see pop message saying app is damaged or broken or unidentified developer.
You need to verify all your rpath with command line otool -l of your executable and yours Frameworks. If you have a local rpath (ex: /user/name/Qt/) in your executable delete it (with this command install_name_tool -delete_rpath).