I help a lot of developers with trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Make sure to add relevant tags — like Gatekeeper, Code Signing, and Notarization — so that I see your post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in antivirus technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing Content in a Bundle Embedding Nonstandard Code Structures in a Bundle Embedding a Command-Line Tool in a Sandboxed App Creating Distribution-Signed Code for Mac DevForums post Packaging Mac Software for Distribution DevForums post Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey API. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. The remaining sections address the most common ones. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. The classic example of this is trying to run a third-party app that contains arm64e code. macOS requires that third-party kernel extensions use the arm64e architecture. In other circumstances, stick to arm64 for your shipping products. If you want to test arm64e code locally, see Preparing Your App to Work with Pointer Authentication. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles For general information the system log, see Your Friend the System Log. Revision History 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

Hi all, I'm developing a 3D modeling C++ application with embedded Python scripting capabilities which targets Big Sur. I want to distribute my application ("MyApp") with a full python package directly integrated into the MyApp bundle (the MyApp.app folder) so that users won't have to install Python manually. So I binded Python3.9 and my app using pybind11, and copied the Python framework folder (all files of the folder of the version 3.9, which is named "3.9") into the "Framework" directory of my App bundle, then locally set the PYTHONPATH and PYTHONHOME environment variables at run time so that they point to the python's Framework folder copied into the bundle. It's working: python scripts can run from my application even if there isn't python installed in the system. However, I have an issue when signing my MyApp bundle. Assuming that I need a python framework package which is universal, correctly signed and has folder structure and files compliant with Apple's bundle specs, I saw too options at first On one hand, homebrew provides signed python packages but for arm64 architecture only, so it must be excluded since I need x86_64 too. On the other hand, the official python website provides universal python packages but they are not signed. I then copied the Package from the official python website and removed many of its unessential components to make it tidy as much as possible, then ran a script that codesign all files that codesign signals as "not signed at all" when running it on the full RizomUV App bundle. Once all files that need to be signed have been signed, I got the following message when running codesign on the MyApp bundle folder: codesign --force --verify --verbose --sign "Developer ID Application: XXXXXXX (XXXXXX)" MyApp.app --option runtime MyApp.app: replacing existing signature MyApp.app: bundle format unrecognized, invalid, or unsuitable In subcomponent: /Users/me/Documents/a_path/MyApp.app/Contents/Frameworks/Python/lib/python3.9 That python3.9 folder, which contains a bunch of python script files (***.py) and some directories which seems to be not compliant with the bundle specifications. This prevents the signature of the full bundle and that's obviously a problem. I'm sure I'm not the only one who integrated Python as a framework into a universal bundle. I could do more investigations but I'm less and less confident that I'm following the right path as I find it overly complicated. There must be a better way right? Any help or feedback would be more welcomed. Best

I have a series of codesign commands that I would run regularly to sign my app. They always worked fine, until I recently upgraded my Mac OS to Monterey and XCode to 13.3.1. Now the same syntax just results in codesign's usage message. Here's one of the commands that fails: codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements "example.entitlements" --sign "Developer ID Application: Company Name (XXXXXXXXXX)" I tried variations also, to no avail, such as this: codesign -s "Developer ID Application: Company Name (XXXXXXXXXX)" --options runtime --timestamp --force --deep --entitlements "example.entitlements" Any idea what I'm doing wrong, and why it stopped working after upgrading? Thanks.

We have a desktop application we build using Cmake and Qt to build. I am able to codesign and notarize the app bundle and got "statusSummary": "Ready for distribution", in the log from notarization. I stapled to the .app and used ditto to zip it again but was still getting unidentified developer when I sent it to coworkers to try. I then ran create-dmg to create a dmg to distribute the application since this is our normal distribution method and was getting unverified developer warnings when sending and trying the application on other systems. I guessed that maybe I needed to codesign and notarize the .dmg as well so I did that and again got "statusSummary": "Ready for distribution", in the log but I am still seeing errors when trying to open and run on other systems. is there an order of operations I am missing in the process or a better way for me to test locally because everything I see on my end says its passing the checks.

I have some third party frameworks that are signed with a v=20200 signature. When I add them to my project and set them to Embed and Sign, the app won't install on my device giving the error The code signature version is no longer supported. I have tried resigning them using codesign -s "Apple Development: XXXX XXXX (BLXXXXXX)" -f --preserve-metadata --generate-entitlement-der XXXSDK.xcframework but the signature always reports v=20200. I tried removing the code sign and letting Xcode do it's thing, but get the same result. Is this a problem with the way the .xcframework was built? Can I fix this without getting it rebuilt?

I get the following error... Warning: unable to build chain to self-signed root for signer "Mac Developer: J I have tried everything.. all of the suggestions listed and still can't clear the problem. Can we get a better description of what the problem is so we might get a better idea on how to fix this. I am running XCode 10.0 on OSX 10.13.6 I need to ship product. Help!! Any help... Thx

I want to (continue to) use XCODE to develop for my personal, local use on my Mac as I have been doing for decades. But on my new computer, in every project, I first try going to the code signing options and select either my developer ID or sign to run locally, and then I choose my personal team name (I'm not professional developing at this point - just learning and running locally.) But on Monterey/M1 and the latest XCode, it won't accept my Personal development team - it just repeats the error "signing for *** requires selecting a development team", even though I selected my Personal Team. I am very desperate to start developing with my new Mac, and any help to get past the code signing problem is greatly appreciated. I just want my projects to compile and run again. I am willing to pay for help.

Hi. I've read a lot of different topics on forums and websites about software signing and notarization, and there is progress, but I need some help. 1. From the beginning: I am building an application on a Jenkins server and downloading the file 'example_app.dmg'. I am enrolled in the Apple Developer Program. 2. Then I use the command to sign the software: codesign --force --sign "Developer ID Application: name_of_my_certificate_in_keychain (number)" example_app.dmg 3. Checking the status: spctl -a -t open -vvv --context context: primary-signature example_app.dmg Result: example_app.dmg: rejected source = Unnotarized Developer ID origin = Developer ID Application: name_of_my_certificate_in_keychain (number) Why is it rejected? 4. Then notarization: xcrun altool --notarize-app \ --primary-bundle-id "example" \ --username "my_AppleID" \ --password "@keychain: NOTARIZED" \ --file "example_app.dmg" NOTARIZED is in the keychain with the generated password on my Apple account. 5. I get: No errors uploading 'example_app.dmg'. RequestUUID = 'number_of_my_request' 6. I check the notarization status: xcrun altool --notarization-info "number_of_my_request" \ --username "my_AppleID" \ --password "@keychain: NOTARIZED" Result: No errors getting notarization info. Date: 2022-05-10 14:15:35 +0000 Hash: hash_number LogFileURL: link_to_log_file RequestUUID: number_of_my_request Status: invalid Status Code: 2 Status Message: Package Invalid Inside the log_file, a lot of files have a status like: The binary is not signed. The signature does not include a secure timestamp. The executable does not have the hardened runtime enabled. Am I doing something wrong or what can I do better? And how I can make empty line here (this forum)?

Example for google.com as an item name, I have two keychain items with the name "Foo", one in KeychainA another in keychainB. When I run the following which password should be retrieved? Password from KeychainA or KeychainB? Does it retrieve items from keychains by prioritizing retrieval from 'default' keychain first? Or it's sorted by the keychain name? or it prioritizes items based on date? security find-generic-password -w -s 'google.com' -a 'Foo' I asked because we often have certs that are duplicated across keychains and when I run the command above, the item is retrieved from a locked keychain. Which causes an OS prompt and that halts our Jenkins/CI.

I have two certs with same name so prevent the ambiguity that codesign has when it finds two certs with same name in the keychain, I tried to create a new keychain and moved the cert I want into it and passed the path with --keychain param to the codesign tool. But it still looks for the cert in the login keychain. What's wrong with the below command? codesign -fs "$CODE_SIGN_IDENTITY" --keychain "full/path/to/codesigning.keychain-db" $FILE

Hi all, I'm attempting to distribute a notarized expiring demo variant of my Mac App Store app (TypeMetal) directly to potential customers as a download on our website, using the procedure documented here: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution I successfully complete the 9 steps listed in "Notarize Your App Automatically as Part of the Distribution Process", including choosing "Developer ID (Distribute directly to customers)" and "Upload (Send to Apple notary service)", and successfully download the resultant .app bundle, but I'm unable to run the app. It looks to me as if the system is attempting to obtain an App Store receipt for the app, when what I want is for this variant of the app to be treated as distinct from the purchased Mac App Store version, and be runnable without purchase. I have tried changing the app's bundle identifier and removing the LSApplicationCategoryType (in the Xcode target's settings, before building), but neither seems to affect these results. I'm left wondering how the system is determining that this is an .app that requires App Store sign-in/receipt-checking. When I copy the downloaded, notarized .app to a different macOS user account, log in as that user, and attempt to launch it there, the system presents a panel, prompting for the user to sign in with their Apple ID: When I attempt to launch the app in my own user account (the one I build and develop in), the system presents the same prompt in a slightly different form: Whether or not I provide a valid Apple ID sign-in in either case, the launched app then terminates with a fatal alert. (Same result in a separate user account as in my own development account.) I would like for the distributed app to be runnable by customers without requiring an App Store receipt. I have verified that my own App Store receipt-checking code is being omitted, as I intend, from the build I that submit for notarization. Is there something I need to do differently to make this work? The notarized app has passed the checks described here: Resolving Common Notarization Issues https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721 I can provide the outputs of the codesign and spctl checks recommended on that page, if that would be helpful. The .app contains one embedded framework (OpenSSL.framework) and one command-line executable (tidy), but I believe they are correctly code-signed. I'm testing this on a 2020 M1 MacBook Air running macOS 12.3.1 (21E258), using Xcode 13.3.1 (13E500a) to do the build, upload for notarization, and export of the notarized result. Thanks very much in advance for any insight you can offer. Troy Stephens Coherence Labs, LLC

Hello! I was able to add the plugin upgrading xcode version to 13. I test my app and everything is working but then i try to archive the .ipa and upload it to the appStore but I face with this error: CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'com.onevcat.Kingfisher' under the iOS application 'WorkoutMinister.app'. With error code STATE_ERROR.VALIDATION_ERROR.90685 for id c3d0e0ae-8bce-4e4f-a335-2244043d4a3d I look for information but it and I know that is caused by embed framework reference inside the xcframwork build but i dont know how to change this.

I have an application made for iPhone and iPad with enabled capability to run natively on M1 Macs. When I try to resign it with an AdHoc profile: codesign --force --deep -s - MyApp.app Application can not be launched anymore with error: "MyApp.app" cannot be opened because the developer did not intend for it to run on this Mac. Contact the developer for support. Is there way to resign it without loosing an ability to run on M1 Mac? Thanks!

After a lot of googling, I'm still unable to find an answer. We are building our product within Azure Pipelines with macOS hosts. After the pipeline is done, we get corrupted packages out of it. I could reproduce it locally with 12.3.1. As you can see below, after overwriting the code sign, it fails to validate. Anyone got any idea how this can happen? Btw, we don't have any embedded bundles, same result without --deep, the notarization reports on the same file: The signature of the binary is invalid. # Force to override any codesign codesign --force --deep --sign "***" --timestamp --options=runtime ***.app # Verify the codesign codesign -vvv --deep --strict ***.app ***.app: a sealed resource is missing or invalid file modified: /Users/***/Desktop/***.app/Contents/MacOs/*** Only one file is having this issue, that is the main binary that is specified in the Info.plist as the startup program.