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.
Related
I have a local development builds of an audio software application, and I'm having problems setting up entitlements so that I can receive audio input (com.apple.security.device.audio-input and/or com.apple.security.device.microphone). This works correctly for "official" builds produced via an IBS pipeline, but never locally.
Based on everything I can see, my local builds are correctly configured - my build is signed and codesign shows the correct entitlements. The app requests other permissions for e.g. disk access. The application appears and is checked in "Security and Privacy" under "Microphone". However: my audio input is silent, and I am not asked for permissions when opening an input device (this is not a code issue: for example, the identical commit hash built on another system, and run on my system work fine). For now, I'm only concerned with my local builds being usable - these are not official / app store builds, or intended for use on other systems than my dev system.
This is not a question about "how to do entitlements", or about this entitlement specifically, but more generally - how do I debug this issue:
Are there other a priori ways to check my entitlements beyond codesign --display --entitlements? Where else should I check that, for a given application / binary, entitlements are set up correctly?
When the application attempts to open an a audio input, and access is denied (presumably) because of entitlements, is this failure logged (syslog etc)?
Are there Apple API's that can provide more detailed error information when an operation fails because of entitlements? Can I log the details of an entitlement failure myself?
I have many builds of the application on my system - debug builds, release builds, branches, old versions etc., but only ever see a single application in e.g. Security and Privacy UI. How can I verify that what I see in the UI is correct for e.g. the particular app package / identifier I'm working with?
Any other debugging tips or workflows would be appreciated.
One note: the build system for this project is Cmake/make/command-line-based rather than Xcode based - all entitlements/signing stuff is being done via Cmake and command line tools (again: this has worked before, and works for some builds), so I would prefer solutions that matched this workflow - Apple's documentation is good, but is usually of the form "do this in Xcode", which is unhelpful here.
Bowtie app is here: http://bowtieapp.com. The binary but not the source is available.
It has the problem on macOS Sierra 10.12.5 Beta that an active firewall causes it to request firewall permissions on every boot. I suspect this can only be resolved via codesigning.
There is an old fix which no longer seems to work:
https://ivadrenaline.wordpress.com/2015/07/07/do-you-want-the-application-to-accept-incoming-network-connections/
You can sign the frameworks, but then when you sign the whole app you get:
/Applications/Bowtie.app/: resource fork, Finder information, or similar detritus not allowed
Googling that error leads to: https://developer.apple.com/library/content/qa/qa1940/_index.html
But while running xattr -cr on the app causes the signing to proceed without error, it still does not prevent the firewall dialog permissions request from appearing.
I have also tried deep versions of the signing process which did not work.
I think Bowtie has the app itself and a helper application, so it may have more than one executable, and be related to this item: Application with multiple executables appears signed but triggers firewall warning
Also:
Why is OSX continually asking for firewall permission for my app which is signed?
This promising answer also did not work:
https://stackoverflow.com/a/40067738/365478
What is the fix for this?
Manually adding the application to the firewall exclusions list via the macOS System Preferences UI worked. The .app was fine, it wasn't necessary to find the executable. I didn't isolate these changes, so it may also be necessary to codesign the app with the failing methods and/or to manually set firewall exclusions via the terminal, as another answer on the following thread suggests.
https://stackoverflow.com/a/10011819/365478
If someone shows how to codesign it properly I'll remark that best answer.
After developing my first Mac app I've decided to submit it to the Mac App Store but it got rejected. Basically my app uses NSOpenPanel for reading Xcode project file and NSSavePanel for saving file after it finishes it's work.
Reviewer pointed out that app is violating 2.30 rule - Apps that do not comply with the Mac OS X File System documentation will be rejected, but I'm unclear why.
When you look at app's workspace you can see it uses CocoaPods for handling dependencies which shouldn't be a problem. Next it has JBLocalizer.framework which is being linked as an embedded library to JBLocalizerApp. JBLocalizerApp is final target sent to the review.
Here is what reviewer pointed out as a problem:
2.30
The application accesses the following location(s):
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBString.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBPostProcessStringsOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadStringsInFileOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadSourceFilesOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadRootFilesOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBFileController.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBFile.gcda'
The majority of developers encountering this issue are opening files
in Read/Write mode instead of Read-Only mode, in which case it should
be changed to Read-Only.
Other common reasons for this issue include:
creating or writing files in the above location(s), which are not valid locations for files to be written as stated in documentation
writing to the above location(s) without using a valid app-id as a container for the written files
Please review the "File-System Usage Requirements for the App Store"
of Submitting to the Mac App Store for the locations apps are allowed
to write and for further guidance.
I'm really not sure how can my app violate access to the library which is being linked to. Any suggestions?
You've got Code Coverage turned on in your project settings.
See QA1514 on how it's turned on, which should help you turn it off.
I have an application that was built with xcode and packed using 'IceBerg' package maker. After making the package I used codesign command to code-sign the application. So I wouldn't get the 'un-indentified developer' message.
Recently one of our client complained about getting the 'un-indentified developer' message even though the Gatekeeper option is set to 'Map App Store and indentified developers'. It is happening only in this clients system.
What could be the reason? Do you have any advice?
You should use "productsign" to sign your packages.
Please see Gatekeeper Unreleased Notes
I've done codesigning and submitting for iOS apps countless times. This time it struck me with the Mac App Store. I'm repeatedly getting the same error message:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I've recognized this 2 topics here on stack overflow:
mas-code-signing-identity-private-key and mac-app-package-identity-not-installed
Nothing inside there solved the problem for me.
Thats how I (most reliably) reproduce this message:
I clean up all my certificates and private keys starting with "Mac Developer" or "3rd Party Mac Developer". Of course also the expired ones.
Revoking all the stuff inside the Mac certification portal.
Create App-ID (did it only once)
Create new certificate for Mac Development. I can only assume that this is comparable to the debugging certificates for iOS development.
Create new certificate for Mac App. Once again I can only assume that this could be something similar to a distribution certificate in iOS-development.
For completion reasons create a new certificate/profile for my system.
Create a production provisioning profile. I can only assume that this might be equivalent to an iOS distribution profile.
I then download all the certificate mess and install it properly. Some go into the Keychain, others got into the Preferences and XCode.
For making sure I restart XCode or even the whole Mac (doesn't change the frustrating outcome anyway).
I go to the project build settings and select the production provisioning profile, because I assume "production" is equivalent to "distribution". Changing the codesigning identity in the target build settings doesn't work either. While Apple claims in it's documentation that for App Store submission the signing identity has to be changed in the project build settings.
I run an archive build.
I select the archive in the organizer and click validate.
This error message appears:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I can't find any pointer to what the term "package identity" actually means. What is most frustrating to me is that this terminology mess in Apples documentation concerning the code signing and submission process appears not very clear and precise to me. At least not as clear and precise as the documentation for the same process concerning iOS App submission (which is using completely different terminology).
Probably I understood something wrong? Thanx for any help or pointer in advance.
OK, I have some important pointers (additional to Apples documentation) for people stumbling over similar issues.
The error message is totally misleading.
Don't take every word in Apples documentation too seriously.
For solving the issue, 2 points have been most significant:
Additional to all the other profile-mess you need 2 certificates for submission to the Mac App Store (contrary to the same process for iOS App Store submission). Both have to be installed together with their corresponding public and private key pairs.
Mac App
Mac Installer
The codesigning needs to be set on the build target, not the project. I don't remember where but this was described wrong side around in one of Apples documentations.
Eventually my submission worked by keeping to those 2 points.
There is an additional issue with Keychain & XCode.
When Xcode uses a certificate, they want one and only one certificate in your keychain. If you have an expired one, as well as a valid one, Xcode often fails the operation.
So you look at your keychain using Keychain Access, and do not see an expired certificate. It is still there! The default setting for Keychain Access hides expired certificates. Goto the View menu and select Show Expired Certificates. Delete all the expired ones, they are not good for anything.
Quit Keychain Acces and Relaunch Xcode. Xcode often requires a relaunch when adding/deleting certificates.
At that point, the Archive Validate process worked for me.
This is what it was for me as well.
Just want to clarify, you absolutely need both Mac App Distribution and Mac Installer Distribution certificates. Thanks Jacque for your explanation above. It should look like this:
Yes the problem is Mac Installer Distribution certificate.
The easiest way to have everything fixed and loose all the troubles just go to Xcode->Window->Organizer->Devices and then on the lower right corner press on Refresh and log in with your account... xcode will generate and download all the certificates and provisioning profiles needed.