I am working on an application written in Qt for macOS environment. In order to generate release build i have set up external server.
I am seeing this:
After generating build, if I download and install the application on Applications folder, when opening it, first I see the popup asking if I am sure to open app downloaded from Internet(Gatekeeper), so I click Open and then app dies.
App works fine if I open it from CommandLine in Terminal.
Checking the attributes of app file I can see that it has com.apple.quarantine. If remove it manually, using xattr -dr com.apple.quarantine application opens without any problem
Any ideas about why it is not launched ??
Thanks is advance
I had the same problem with my software and raised a developer incident which allowed to find the root cause:
When launched the first time with the quarantine attribute, Gatekeeper will pass an additional command-line argument.
From what I could observe, it is of the form:
-psn_0_<some sequence of numbers>
e.g.
-psn_0_2445909
Qt's QCommandLineParser rejects unknown arguments and calls exit(1); in that case.
Thus it is necessary to filter argc / argv and remove that bogus argument before passing them to Q{Core,Gui,}Application.
Related
I want to be warned by Mac gatekeeper whenever I attempt to use an app for the first time that is not signed through the store. However, I'm having trouble using LibreOffice Vanilla by clicking on files with relevant extensions (eg .ods, .odt). It seems to consider each file a different app and I think needs me to authorize it individually. Double-clicking file yeilds '"myfile.odt” can’t be opened because it is from an unidentified developer.'
Right-clicking and using Open with ... LibreOffice Vanilla yeilds:
'"myfile.odt” is from an unidentified developer. Are you sure you want to open it?'
I don't find the 'help' at https://support.apple.com/en-ca/HT202491 helpful. How can I configure OS X so it lets me open LibreOffice files with a double-click yet still have GateKeeper check other new applications that are not signed?
You can bypass gatekeeper if you select a file type to "always open with" a certain type of program. Other programs that are not of this type will still invoke gatekeeper, so you won't have the security issues. So if you set your .odt file type to always open with libreoffice, the issue should go away.
See this:
https://apple.stackexchange.com/questions/193233/gatekeeper-wont-let-libreoffice-open-csv-files
I'm on MacOS X, and I'm pretty new to app-bundle-type things. I am writing a program that opens a window and registers mouse input -- not a command line tool. When I compile my code (written in C, if that is important) into an executable file (a "unix executable file") and then run that file directly (by double clicking it, for example), a terminal window pops up, and then the program's window pops up. Likewise, if I navigate to the directory of the executable and open it from the command line, it pops open /another/ terminal window and then the program's window.
However, if I wrap the executable in a bundle (thus, I suppose, turning it into a proper "app"), then when I run the app, either by double clicking or from the command line, the program's window opens and no new terminal window is created. Is this merely a property of the "app bundle"'s architecture? Or is there a way that I can run the raw executable without incurring another terminal window? I suspect that I'm misunderstanding something fundamental. Thanks in advance!
I believe what you're seeing is correct. In order for a separate window to not pop-up, you'd need to encapsulate it into a bundle.
Launching by double-clicking a bundle, or using the 'open' command from Terminal uses Apple's Launch Services, which maintains a list of known (registered) applications. When an application (bundle) is introduced to the system, it is registered with Launch Services and associated with its URI (e.g. com.apple.calculator), which is present in the bundle's Info.plist
Other items in the Info.plist tell launch services how to handle the application, such as checking if the minimum or maximum version of the OS has been exceeded, or whether or not to display a dock item.
A lone binary doesn't have an associated Info.plist manifest, so its behaviour can't be varied and a Terminal window is opened.
Bare executable files are essentially treated as documents by Launch Services (the framework that the Finder, Dock, and open command use when you open stuff). The application which handles such documents is Terminal. So, when you open an executable in that fashion, it launches Terminal if it's not already running and tells it to open the document. Terminal does this by opening a new shell window and auto-typing the path to the "document" as a command line.
Launch Services handles bundled apps as, well, apps. If the app is already running, it activates it and possibly has it open a new untitled window. Otherwise, it launches it.
As Rob Napier notes in the comments, if you run an executable directly from the command line (or if some already-running app launches it using NSTask or fork+exec), it will simply run. Launch Services won't be involved, so Terminal will not be asked to open the executable as a document.
I recently discovered Emscripten, and after downloading it, I decided to see if I could get it to work with Code::Blocks, so that I could easily test my applications to see how they performed when running as JavaScript.
I created a new compiler configuration, and set up all of the toolchain executables, except for the resource compiler (which doesn't seem to give me any problems), and the debugger. I wasn't really sure what to put in the debugger, because I remembered the debugger field as being a text-box. But when I looked, all that was there was a drop-down menu.
I managed to find a "Debugger" menu in the "Settings" menu, and when I opened it, there was a button called "Create config".
I created a new configuration, and pointed the executable path to "node.exe" (which runs .js files). I then went back to the compiler settings, and chose my new debugger in the drop-down.
I then tried to build and run a simple hello world application. But once it finished building, it gave me the message Execution of '[my file] ' in '[my project folder] 'failed. The actual build seemed to be successful, so I decided to manually run node.exe from the command line to see if I had configured the debugger incorrectly. And as I expected, it ran successfully.
While I was glad that I had successfully configured the compiler, I still was confused as to why the app didn't want to run. I also set Emscripten to create HTML files instead, to see if Code::Blocks would somehow recognize the appropriate program, and open it in the web browser instead. Of course that didn't work either.
What I am trying to figure out, is how I configure Code::Blocks' run command. Perhaps the debugger isn't even the right place to be looking. But I really need someone to help me figure out how I can configure this in Code::Blocks, as this is currently the only thing that is really giving me any trouble.
Thanks.
Possible but less ideal solution:
After some time, I was able to come up with a solution. However, I am sure that there are better alternatives.
To use this method:
Create a new build target called RunScript.
Set the compiler to No Compiler.
In the project properties, set the type to Console application.
Uncheck Auto-generate filename extension, and set the output filename to RunButton.bat.
Create a new file called RunButton.bat (or whatever you entered as the output filename).
Whatever you put in RunButton.bat will now be executed when you click the run button.
I also created a new virtual target that contained my RunScript target, and my main target, so that I don't have to switch targets whenever I want to test my application.
Problems with this method:
While this method does work, it is not ideal, as it requires you to have two extra targets (including the virtual target that I made for convenience). I would rather be able to just have everything contained in one target.
Slightly better solution:
A new solution that I decided to use, is to simply use the configure tools menu to create a tool that points to a batch file that runs my compiled programs.
To use this method:
Go to Tools>Configure Tools...>Add.
Fill in the name, and point the executable to the script that you want to run when this tool is used.
Fill in any needed parameters. You can use the built in ${TARGET_OUTPUT_FILE} macro to pass your output application as a parameter.
You can now use your tool by going to Tools>{My tool}, but you can set a hotkey by going to Settings>Editor...>Keyboard shortcuts.
Click the plus button by Tools, and click on your tool to set a shortcut for you tool.
Problems with this method:
While this method does eliminate the extra build targets, it doesn't let you run your script or run non-executable files by clicking the run button; which was the original intent. On top of this, you have to create a new tool anytime you want to add a new script.
I am hoping that someone else will be able to show me a better way of doing this, but for now this will work.
Might be a little late, but I was able to get the codeblocks run button to run any command by using a few post-build steps. The reason I need this is because my laptop has nvidia "optimus" and in order for my output program to see the discreet graphics card, I have to run it with the optirun prefix. So I added the following to the post-build steps in build options:
mv $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE)_bin
echo #!/bin/sh > $(TARGET_OUTPUT_FILE)
echo optirun $(TARGET_OUTPUT_FILE)_bin >> $(TARGET_OUTPUT_FILE)
chmod +x $(TARGET_OUTPUT_FILE)
It basically renames the output binary and creates a script replacing the original output binary name. When pressing the run button, the script is executed instead of the output.
On windows, you might have an issue running an exe extensioned file as a batch script so what if you generate the output file with a bat extension like in your first method, but with compilation and then rename it to exe in the post-build like this:
move $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).bat $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).exe
echo [WHATEVER YOU NEED TO RUN] > $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).bat
My (sandboxed) OSX application is trying to launch biber (a bibliography tool for LaTeX). However it fails to launch and I get the following message saying that the application has marked biber as quarantined in Console.App.
25/03/2013 16:44:15.000 kernel[0]: exec of /private/var/folders/s1/70f5my9n6wq0_kk7bcxjslhh0000gn/T/com.abc.XYZ/par-64756e63616e737465656c65/cache-ef42c8d5d44e40bdd24828b0ae70de275e379c88/biber denied since it was quarantined by XYZ and not approved by Gatekeeper, qtn-flags was 0x00000002
This does not happen with any of the other binaries invoked by the application.
This application has an active SSB for the whole harddrive so there are no issues launching, or accessing, external files.
Why and how am I marking that file as quarantined, and how to I remove the quarantine so that it can execute? Thanks for your help.
EDIT If it helps, the contents of that directory are
biber
libperl.dylib
running ls -l#eOd shows them both to have the attribute com.apple.quarantine, however I'm not sure what copied them into that directory, or how they gained that flag. The original copies are not quarantined.
Looks like this 'biber' is not an application download from Mac App Store or identified developers (with Apple Developer ID). So you must manually allow its launch.
Usually there are three ways to do this:
Right click on application and click "Open" from the context menu. There will be a warning, just click "Open". OSX will remember your choice and next time it will open.
You can change Gatekeeper's settings: "System Preferences" -> "Security & Privacy" -> "General" tab. Unlock to make changes. Choose "Anywhere" in the "Allow applications downloaded from" section. Note: it decreases security and there will be a warning about it with the proposal to use first solution.
Remove 'quarantine attribute' from the app. In terminal run command: xattr -d com.apple.quarantine <your_app>
I prefer the last solution. All solutions are for the applications, but I think will also work for the utility.
I have another question dealing with app sandboxing. So I need access to the users' home directory and at the same time the app should be able to shut down the Mac. This requires to not using sandboxing.
My problem is that I don't know how to remove sandboxing and being able to submit the app to the Mac App Store. I think that the archives are sandboxed because I had turned it on once..
How to remove sandboxing from the archives properly?
Thanks for your help!
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
If I understand what you are asking correctly, you'll need to remove the entitlements.plist from your project and make sure that the Summary view of your target in Xcode has sandboxing turned off:
As Derek Wade pointed out, you can make an App like GarageBand X (which behaves obnoxiously with third party plugins like Amplitube due to Sandboxing) NOT run in a sandbox by editing the binary itself with a HEX editor like HexFiend. Look for:
<key>com.apple.security.app-sandbox</key>
Immediately following that bit you'll see the true tag, which as suggested I switched to 'fals' (no extra bytes) and now GarageBand will happily interact with third party VST plugins. Huzzah.
I found if you go into the .app package, under Contents/MacOS, there should be a binary file that matches the name of your app. Copy that file to your desktop. Edit the desktop copy of the file with TextEdit. You should find within the file, the text representation (xml) of the Entitlements for the app. Find the Sandbox entitlement flag (usually set to <true/>) and change it to <false/>. You will have to unlock the file when editing. Save the file (located on the desktop). Rename the original file in the .app package (i.e. append .old to the filename). Copy the desktop file back to the .app Package location (you may have to authorize it). This should remove the sandboxing.
You cannot remove Sandbox if the user ran you application via Sandbox.
That's the whole point - don't you think ?