This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Don’t Run App Store Distribution-Signed Code App Store distribution-signed code is intended to be uploaded to the App Store. You can’t run it locally. Except when you can! To avoid confusing yourself, don’t attempt to run App Store distribution-signed code. Intended Purpose App Store distribution-signed code is intended to be uploaded to the App Store. When you upload code to the App Store, it checks the code’s signature as part of the distribution process. App Store distribution-signed code is not intended to be run locally. That’s what development-signed code is for! If you want to test your App Store product before shipping it to users: For day-to-day work, use Development distribution. For limited testing, use Ad Hoc or Enterprise distribution (not available on macOS) or Developer ID distribution (only available on macOS). For wider testing, use TestFlight. Note Not all capabilities are supported by Developer ID distribution. For the details, see Developer Account Help > Supported capabilities (macOS). macOS Gotcha Most Apple platforms completely block you from running App Store distribution-signed code. The exception here is macOS, which runs distribution-signed code under some circumstances. Specifically, macOS runs distribution-signed code if the code claims no restricted entitlements. If the code claims a restricted entitlement that claim must be authorised by a provisioning profile. It’s not possible to create a profile that does that: A macOS App Development or Developer ID profile never authorises the certificate from your distribution signing identity. A Mac App Store profile never authorises execution on your machine. The lack of a valid profile means that the restriction entitlement is not authorised and your app will crash on launch. For more details on what that crash looks like, see Resolving Code Signing Crashes on Launch. For detailed information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. Even though there are some cases where App Store distribution-signed code will run on the Mac, the general rule is the same there as it is for other platforms: Don’t run App Store distribution-signed code. Revision History 2022-06-01 Added App Store to the title to make the subject clearer. Made similar changes throughout the text. 2022-05-31 First posted.

After uploading a new App to the App Store Connect i receive an e-mail stating:ITMS-90034: Missing or invalid signature - The bundle '...' at bundle path 'Payload/...' is not signed using an Apple submission certificate.The App don't use any capability.I've used Xcode to upload, as in a previous App which now is on the App Store.All the apps use the default configuration: "Automatically manage signing", Provisioning profile "Xcode Managed Profile", Signing Certificate Apple Development: ############The requested Signing Certificate is present in the keychain in 3 versions, the last one is valid (the older 2 are revoked).What I should correct?

Our app is weakly linked to a framework from a third-party vendor: /Library/KeyAccess/KeyAccess.app/Contents/SharedFrameworks/KeyAccess.framework/KeyAccess Our app is signed using our developer ID certificate with: --options runtime --timestamp --entitlements ourApp.entitlements Since the 3rd party framework is signed with a different developer ID, the entitlement file requests and disables library validation: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation?language=objc We have verified the code signature using the following commands: codesign --verify --strict --verbose ourApp.app codesign -dvv ourApp.app spctl -vvv --assess --type exec --ignore-cache --no-cache ourApp.app No issues are reported. We generate a dmg we code sign that too, then successfully notarize the dmg and staple the report. When viewing the log provided during notarization no issues are shown, all binary content has been properly signed. Unfortunately, if the dmg is downloaded from an online source we get a Gatekeeper warning indicating the developer cannot be verified. If we omit the entitlement (which will result in not being able to use the 3rd party framework, but the application will otherwise run) the Gatekeeper dialog disappears. Since this issue appeared only after we upgraded from Qt 5 to Qt 6, we created a small test app that just shows a "Hello World" message. In this case inclusion of the entitlement is not a problem until we attempt to pull in a trivially simple framework that we ship within the application bundle (QNtp.framework). We cannot find any code within this tiny library that e.g. uses a private API or anything else suspicious. If we bake the QNtp code into the test application directly instead no Gatekeeper warning is shown. Is there some way to get a report on WHY Gatekeeper is rejecting the code signature and notarization of the sample or our full app? Unfortunately tools like Max Inspect and Taccy have not yet revealed the cause of the issue. let myEmail = "w" + "stokes" + "@snapgene.com"

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Gatekeeper Problems Gatekeeper strives to ensure that only trusted software runs on a user’s Mac. It’s important that your code pass Gatekeeper. If not, you’re likely to lose a lot of customers, and your users’ hard-won trust. There are three common Gatekeeper problems: App blocked by a dangling load command path Lack of notarisation Command-line tool blocked by Gatekeeper The first problem is by far the most common. For the details, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. For general information about Gatekeeper, read Apple > Developer > Signing Mac Software with Developer ID and Apple > Support > Safely open apps on your Mac. IMPORTANT This post focuses on Developer ID-signed code. Gatekeeper should not block App Store apps. If an app downloaded from the App Store fails to run, it’s likely to be some other trusted execution issue. For more about this, read Resolving Trusted Execution Problems. Identifying a Notarisation Problem Gatekeeper requires that your app be notarised. If not, it will block the execution of your app with a generic, user-level message. If you find your app blocked by Gatekeeper, check if this is a notarisation issue by looking in the system log for an entry like this: type: info time: 2022-05-11 14:57:21.812176 -0700 process: syspolicyd subsystem: com.apple.syspolicy category: default message: ticket not available: 2/2/8b7410713591e6c79ea98f0132136f0faa55d22a Note If the ticket details show as <private>, enable private data in the system log. For information on how to do that, see Recording Private Data in the System Log. For general information about the system log, see Your Friend the System Log. The long hex number is the code directory hash, or cdhash, of the offending code. In this example, it’s the cdhash of the app itself: % codesign -d -vvv /Applications/NotNotarised.app … CDHash=8b7410713591e6c79ea98f0132136f0faa55d22a … However, in some cases it may be the cdhash of some library referenced by the app. For more information about cdhashes, see TN3126 Inside Code Signing: Hashes. Resolving a Notarisation Problem The obvious cause of this problem is that you haven’t notarised your app. For information on how to do that, see Notarizing macOS Software Before Distribution. If you have notarised your app and yet you still see this problem, something more subtle is happening. For example, your app might reference a dynamic library that wasn’t seen by the notary service. To investigate this: Fetch the notary log for your app. For advice on that, see Fetching the Notary Log. Confirm that the notary log matches the app you installed. Look in the notary log for the sha256 property. Its value is a SHA-256 hash of the file received by the notary service. Check that this matches the SHA-256 hash of the file you used to install your app. If not, see Hash Mismatch, below. Search the notary log for the cdhash value from the Gatekeeper log message. If the notary log doesn’t contain that cdhash, that code wasn’t included in the notarised ticket. It’s possible that you failed to submit the code to the notary service, that it was switched out with a different version after you notarised your app, that it was package in some way that the notary service couldn’t see it, or that something went wrong within the notary service. Hash Mismatch If you stapled your notarised ticket to the file used to install your app then the hashes in step 2 of the previous section won’t match. What to do depends on the file type: If the file used to install your app was a zip archive (.zip), you definitely have the wrong file. Zip archives don’t support stapling. If the file used to install your app was a signed disk image (.dmg), compare the disk image’s cdhash with the cdhash for the disk image in the notary log. If those match, you know you’re working with the same disk image. To dump a disk image’s cdhash, run the codesign tool as follows: % codesign -d -vvv DISK_IMAGE … CDHash=d963af703ac2e54af6609e9ad309abee7b66fae2 … Replace DISK_IMAGE with the path to your disk image. If the file used to install your app was a disk image but it wasn’t signed, switch to a signed disk image. It’s generally a better option. If the file used to install your app was an installer package (.pkg), there’s no good way to know if this is the correct package. In this case, modify your notarisation workflow to retain a copy of the file before it was modified by stapler. Tool Blocked by Gatekeeper If your product includes a command-line tool, you might notice this behaviour: When you double click the tool in Finder, it’s blocked by Gatekeeper. When you run the tool from within Terminal, it works. This is a known bug in macOS (r. 58097824). The issue is that, when you double click a tool in the Finder, it doesn’t run Gatekeeper’s standard execution logic. Rather, the Finder passes the tool to Terminal as a document and that opens a window (and associated shell) in which to run that document. This triggers Gatekeeper’s document logic, and that logic always blocks the tool. There are two ways around this: Embed your tool in an application. If the user runs the application first, Gatekeeper runs its normal application check. If the user allows the app to run, Gatekeeper records that decision and applies it to the app and any code within the app, including your tool. Install your tool using an installer package. When the user goes to install the package, Gatekeeper checks it. Assuming that check passes, Gatekeeper does no further checks on the content it installed.

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving App Sandbox Inheritance Problems 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 tripping over one of the following problems: Nonheritable entitlements Changing sandbox Nothing to inherit Nonheritable Entitlements The most common cause of this problem is also the most obscure. If you have a sandboxed app with an embedded program that you run as a child process, a crash in _libsecinit_appsandbox is most likely caused by the embedded program being signed with entitlements that can’t be inherited. Imagine an, SandboxInit, with an embedded helper tool, NotHeritable. When the app runs the helper tool as a child process, the helper tool crashes with a crash report like this: Exception Type: EXC_BAD_INSTRUCTION (SIGILL) … Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_secinit.dylib … _libsecinit_appsandbox.cold.7 + 49 1 libsystem_secinit.dylib … _libsecinit_appsandbox + 2096 2 libsystem_trace.dylib … _os_activity_initiate_impl + 51 3 libsystem_secinit.dylib … _libsecinit_initializer + 67 4 libSystem.B.dylib … libSystem_initializer + 286 5 dyld … invocation function for block in dyld4::Loade… 6 dyld … invocation function for block in dyld3::MachO… 7 dyld … invocation function for block in dyld3::MachO… 8 dyld … dyld3::MachOFile::forEachLoadCommand(Diagnost… 9 dyld … dyld3::MachOFile::forEachSection(void (dyld3:… 10 dyld … dyld3::MachOAnalyzer::forEachInitializer(Diag… 11 dyld … dyld4::Loader::findAndRunAllInitializers(dyld… 12 dyld … dyld4::APIs::runAllInitializersForMain() + 38 13 dyld … dyld4::prepare(dyld4::APIs&, dyld3::MachOAnal… 14 dyld … start + 388 The helper tool has trapped within _libsecinit_appsandbox. Look at the entitlements of the helper tool: % codesign -d --entitlements - SandboxInit.app/Contents/MacOS/NotHeritable … [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.inherit [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true The com.apple.security.app-sandbox and com.apple.security.inherit entitlements are fine: They configure the program to inherit its sandbox from its parent. The problem is the com.apple.security.get-task-allow entitlement, which is not compatible with this sandbox inheritance. The com.apple.security.get-task-allow entitlement is often automatically injected by Xcode. For information on how to prevent this, see Embedding a Command-Line Tool in a Sandboxed App. Some entitlements are compatible with sandbox inheritance. Unfortunately that list of entitlements is not documented (r. 93582428). The most commonly use ones are the hardened runtime exception entitlements documented in Hardened Runtime. The other entitlements on the list are pretty obscure. Changing Sandbox Another cause of a trap within _libsecinit_appsandbox is the child process trying to set up its own sandbox. If a sandboxed process runs another program as a child process, that child process always inherits its sandbox from the parent. If the program’s executable is signed with com.apple.security.app-sandbox but not com.apple.security.inherit — that is, it tries to set up a new sandbox — it will crash in _libsecinit_appsandbox. A process is not allowed to change its sandbox. To check for this problem, look for the following in the crash report: Application Specific Signatures: SYSCALL_SET_PROFILE This indicates that the process tried to setup its sandbox profile but that failed, in this case because it already has a sandbox profile. To fix this problem, either: In the child, add the com.apple.security.inherit entitlement so that it inherits its sandbox from the parent. In the parent, run the program so that it’s not a child process. For example, you could launch it using NSWorkspace. Nothing to Inherit Another cause of a trap within _libsecinit_appsandbox is when a nonsandboxed process runs another program as a child process and that other program’s executable has the com.apple.security.app-sandbox and com.apple.security.inherit entitlements. That is, the child process wants to inherit its sandbox from its parent but there’s nothing to inherit. To check for this problem, look for the following in the crash report: Application Specific Information: Process is not in an inherited sandbox. There are three ways you might fix this problem: Sandbox the parent. Unsandbox the child. Run the child in its own sandbox by removing the com.apple.security.inherit entitlement.

When opening a pkg file on Mojave and Catalina I'm seeing following Package Authoring Errors in Installer log (/var/log/install.log):Package Authoring Error: &lt;background&gt; has an unsupported MIME type: image/data Package Authoring Error: &lt;background_scaling&gt; has an unsupported MIME type: X-NSObject/NSNumber Package Authoring Error: &lt;background_alignment&gt; has an unsupported MIME type: X-NSObject/NSNumber Package Authoring Error: &lt;layout-direction&gt; has an unsupported MIME type: X-NSObject/NSNumberwhich is weird because background is defined in pkg Distribution XML as:&lt;background file="background.tiff" alignment="bottomleft" scaling="none" mime-type="image/tiff"/&gt;based on specification of Distribution file in https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.htmlSimilar problems can be seen even on pkg installers that contain no background XML element. That also includes pkg files downloaded from Apple website.Is there any explanation where these errors are coming from?

In one of the applications that I develop, since version 9.3 of Xcode, an embedded target binary that is launched from the main application using NSTask now fails to launch with the following error message:Sandbox: [AppName(App PID)] deny(1) forbidden-sandbox-reinitI couldn't find much information about it and it's not clear what change happened in Xcode 9.3 (also happens in 9.4 beta 1) that causes this to fail.

i have a mac app,like simpholders app,to find and manager simulator's sandbox and gouse NSTask exe command:/usr/bin/xcrunwill show errorxcrun: error: cannot be used within an App Sandbox.

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

I'm trying to get a pkg file notarized.The notarization process worked fine for me until some day ago.Now, when I run the altool command, I get this error : *** Error: To use this application, you must first sign in to iTunes Connect and sign the relevant contracts. (1048)I have checked https://developer.apple.com/account/ and https://appstoreconnect.apple.com/agreements/ too see if you have any pending agreement, but there is nothing there.The command I use is 'xcrun altool --notarize-app --primary-bundle-id $MYBUNDLEID --username $MYUSERID --asc-provider $MYTEAMID --password $MYAPPPASSWORD --file $MYPKGFILE'The last time the altool command worked for me was on the 29 May.Any idea what is going wrong here?

I am yet another another developer facing the issue of having a notarized application cryptically blocked by GateKeeper with the unhelpful "unidentified developer" message. I followed Eskimo's instructions of combing the system logs, and caught an event by XprotectService: File /Applications/Cook-a-Dream.app/Contents/Resources/app_packages/PySide6/lupdate failed on rPathCmd /Users/qt/work/install/lib/QtCore.framework/Versions/A/QtCore Googling around, I found some people reporting similar problems (with other libraries) being fixed by detecting and fixing this kind of problem by deleting/changing some of the rpaths with install_name_tool. The questions: How do I confirm if the issue is indeed one of rpath? What are the general "rules" that govern what is allowed or not allowed in terms of rpaths for GateKeeper? Can I add a prophylactic step to my workflow to detect those issues before notarization?

We have run into a security scoping issue with the newer macOS releases (specifically macOS 11.6.x and macOS 12). First and foremost, all of our code is signed and notarized. Our software is made of multiple parts and its mainly a plug-in for Adobe's software products (so its distributed outside of the app store). When you install our software, during the installation process a helper app is also installed in addition to the plug-in for Adobe's software. When the plug-in is invoked from the Adobe application the plug-in then launches an external helper that is installed in the Library/Application Support folder. The external helper app performs the brunt of the computation. We use openApplicationAtURL to launch the faceless background helper app but with newer macOS releases sometimes it gets terminated after launching immediately. The user needs to double click it once from what we have observed. We suspect this is due to a macOS security scope (thats the only conclusion we can come up with). This behavior never used to exist before (macOS 10.15 or earlier). This doesnt occur with all users but a handful of people and on newer macOS releases. We are wondering what can be done to solve this or what are we doing wrong? Do we need to file a bug report?

Hi. I want to automate test installation and uninstallation of network extension software. However, it looks like whenever I install the gatekeeper and another pop-up always blocker for automation. My app is fully notarized and stapled, but it seems like it is almost impossible to bypass those two pop up. I want something similar funcitonality of windows Test Mode.

So I've enabled Hardened Runtime on my app but want to test it actually does what it is meant to do.So I put in a simple couple of calls to location services on a button: CLLocationManager* locMan = [CLLocationManager new]; [locMan startUpdatingLocation];and expected my app to crash on Mojave since I hadn't ticked the "Location" option in the "Resource Access" section of the Hardened Runtime capabilities.Instead it carried on as normal and I saw the Location StatusItem show up in the menu bar with my app listed as something that was using Location services.So now I'm wondering if Hardened Runtime is really turned on for my app or not. Or am I misunderstanding its usage?FYI - My app is distributed via Developer ID provisioning, not the App Store.