I'm working on a QT app for OS X that uses multiple executables. We sign the .app by signing each executable within the .app, then signing the whole .app with the "-f" option. This is the procedure Apple recommended when we contacted them.
However, each time our app starts, the user is prompted with a warning that our application wants to connect to the internet. This warning is repeated every time the application is restarted, even if the user chooses to grant it access.
Any suggestions for where our process could be going wrong would be useful. For what it's worth, all executables and the .app itself have valid signatures according to codesign.
Related
I have a MacOS app and want to distribute to beta users as DMG file outside AppStore.
I have read some articles about how to notarize an app and follow the steps to successfully notarize the DMG file without any problem.
My development machine runs on MacOS 10.14, and XCode version is 10.1.
However when I try to check the notarized DMG file on another testing machine which runs on MacOS 10.14.5 (by sending the file via AirDrop, or download from my website), I still see the popup from GateKeeper with message "'myApp.dmg' can’t be opened because Apple cannot check it for malicious software." on that machine.
It seems Gatekeeper does not work properly to check notarized DMG file. Is there anybody having the same problem and how to fix that?
Short answer
It could be due to an RPATH referencing a path outside the App bundle. Removing this RPATH would resolve the issue.
Inspecting log files
You can find extra information about the rejection (after trying to launch the blocked app) in the Console.app. Note that you should open the Console.app, before trying to open your blocked app, otherwise not all messages may be logged. You should look for process XprotectService in the logs of your device (i.e. choose your device in the left side bar of the Console.app). If the RPATH is indeed the problem, you should find a record like this:
XprotectService: [com.apple.xprotect:xprotect] File /path/to/your/executable/or/library failed on rPathCmd /rpath/causing/the/problem (rpath resolved to: (path not found), bundleURL: /path/to/your/bundle.app)
Inspecting these log files may give you a key to solve other issues too.
Note that I received the following information from an Apple engineer:
Gatekeeper does not inform users via UI about the specifics of the
error, though it is in the logs for developers to look at. The
notarization process is purely about a detecting malicious software
and does not replicate Gatekeeper enforcement. You still need to get
software notarized and test with Gatekeeper.
We are looking to provide better tooling for developers in the future
to pre-flight some of these common errors.
Contact Apple
If you are not able to solve your issue with the above information, you may want to contact Apple itself using the Feedback Assistant. They do not respond very quickly (~1-2 weeks), but the answers are rather to the point.
My application was working good before I added one library and a sub-project(both created by me). All are code signed with same value.
If I create a local DMG (using build-script) then it is getting installed on my system, also in other system. But the build taken from Anthill pro fails to pass the OSX Gatekeeper and shows "Un-Identified developer" issue.
What could be the issue that makes the same DMG to behave differently?
I recently dealt with an issue with using a build server to sign an application. It signed fine, but then when we distributed it through our website, our users were asked to "Move to Trash" by OSX. My scenario was a little different, as I was using Jenkins, but perhaps the problem is the same.
I solved the issue by elevating our jenkins user up to an admin, and then running codesign with sudo.
I think this has something to do with signing as a developer vs. signing for distribution. If you download a signed package and your application was signed without distribution privileges, the extended attribute "com.apple.quarantine" gets places on the app package (check it by opening terminal and typing 'xattr [path-to-package]')
I'm working on an app for Mac OS that consists of three binaries:
The main app, to be installed in the Applications folder.
A widget (for OS X Yosemite)
A LoginItem that monitors some stuff in the background (daemon-like, always running)
All three binaries connect to a certain web service with the same OAuth token. The token is retrieved by the main app (on first run, after the user signed in to the service) and stored in the system's Keychain.
To make sure the other two parts of the app can also access the same token, I'm trying to set up Keychain sharing. In Apple's Developer Portal, I've created three App Store Provisioning profiles, one for each binary. All of them are signed with the same developer certificate ("3rd Party Mac Developer Application").
In this situation, none of the binaries will run on my development system, citing "Code Signature Invalid". Also, in the system console, taskgated writes this message: "killed [app] because its use of the keychain-access-groups entitlement is not allowed (error code -67050)".
It is worth nothing that in the capabilities page of each target in Xcode, the Keychain sharing capability was enabled without any error whatsoever.
How do I solve this issue? The only thing I've came up with is simply disabling Keychain sharing, but this will require the user to click (Always) Allow when running the widget for the first time.
Another solution would be to eliminate the keychain altogether, but storing a OAuth token in an unsafe place like NSUserDefaults is not the way to go. I can't find a secure alternative for the keychain, which I think would be the best solution if it works anyway.
I developed a Windows app using C++ and QT library. The app doesn't require elevated privileges to run.
I'm going to distribute my app as an MSI installer downloaded from a website. The installer will be signed using my signed certificate.
However, I haven't signed the EXE file and I don't see any issues with that. There's no security warning shown when I start the app after the installation.
So the question is, should I sign the EXE file as well? If I don't sign it, will there be any issues?
For example, after I downloaded the Dependency Walker tool, it shows me a security warning about an unverified publisher every time I run it. My EXE file isn't signed as well, but I don't see any warnings.
I'm wondering if I can encounter any issues if I release the unsigned EXE file within my signed MSI installer.
It would certainly be preferable for the EXE file to be signed, but it is not ordinarily mandatory. Windows will not warn users when running an unsigned executable file unless the file has a zone identifier or is being elevated ("run as administrator").
However, unsigned files are more likely to experience false positives from security software, may cause users or administrators to be concerned about the trustworthiness of the file and/or process, and are more difficult for administrators to whitelist in high-security environments.
Generally speaking, if the container (the MSI file) is signed and therefore has not been tampered with between its creation and use by the customer then you can trust the content when it gets extracted. Signing is something used mostly at deployment, whether via MSI install or installing a driver, or when you transfer the file to someone else. If there were a scenario where you'd ask some other person or company to use that executable outside of installing it from the MSI file they would probably prefer that it be signed to verify that it's from you and your company.
How do I change what files are signed by install4j's codesigning on Mac OS X?
Specifically, none of my application's files (including its jar file) are signed. This defeats the purpose of code signing entirely. So, I would like to fix this.
I would also like to do the same on Windows, but it's possible that this is already handled correctly (I have not yet checked).
The purpose of signing not that everything that can be signed in any way is actually signed.
Windows reduces UAC dialogs and shows them with a different warning level if executables are signed. Each launcher that requests elevated privileges has to be signed so that includes the installer, the uninstaller and possibly your launchers.
Mac OS X has a "gatekeeper" that checks if an application bundle that was downloaded from the internet is signed. If not, it will not allow you to run it directly. That's why the installer application bundle has to be signed. Gatekeeper is not concerned with any application bundles that are installed by the installer, so they are not signed by default. This is mostly a good thing, since otherwise you would not be able to modify the Info.plist files of your launchers after the installation.
If you use entitlements for gaining access to specific features on Mac OS X your launchers need to be signed as well. You can specify an entitlements file on the "Executable info->Mac OS X options" step of the launcher wizard, and select "Sign installed launchers" on the "Installer options" step of the Mac OS X media file wizard.
install4j is not concerned with signing JAR files. If you need this feature for some reason, you have to do this in your build process.
#Ingo, it is also true that launcher signing is required for certain restricted functions an application may need (e.g. opening a network socket). I also think I should mention the "Sign installed launchers" on the "Installer options" step is not available on the "Mac OS X single bundle" media type, so users will need to choose another media type if they require launching signing.
This wasn't clear in the documentation, so hopefully this comment can save someone some time.