Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code. General: DevForums tag: Gatekeeper Developer > Signing Mac Software with Developer ID Apple Platform Security support document Safely open apps on your Mac support article Hardened Runtime document Testing a Notarised Product DevForums post Resolving Trusted Execution Problems DevForums post App Translocation Notes DevForums post WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04:‍32) WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46) Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I developed an app including driver extension. So I tried to distribute it to users. Of course, it works fine in my Mac. I pressed "direct distribution" through the distribution menu in xcode, but the error occurred as below. I also checked that distribution are fine with TestFlight(internally), checked unregistered mac device. I can't figure out what's wrong, so I'm asking for help. Thank you.

(Skippable) Backstory: I have an app that customers initially install by: Going to our website in a browser, downloading a (notarized) disk image, mounting it, opening the (Developer ID-signed) installer package therein, and following the prompts to completion. Once installed, this app has a button you can click that will check for updates and possibly install them. When you click this button: Our app contacts an HTTPS API on our servers to see if there is an update If there is an update, the API responds with a download URL to the aforementioned notarized disk image, and the SHA-512 hash of the disk image Our app downloads the disk image, and verifies the SHA-512 hash of the download Our app mounts the DMG Our app uses /usr/sbin/pkgutil --check-signature (although I do hope to switch to SecStaticCodeCheckValidity() in the future) to verify that the OS thinks that the installer package is properly signed, and also that the organization unit on the leaf certificate for the code signing key used to sign the installer is exactly equal to our Apple Team ID Our app uses /usr/sbin/installer -package ... -volinfo to verify that the installer package thinks it can install onto the host Our app uses /usr/sbin/installer -package ... -target / to install the software update For 98%+ of our users, this update process works great. For a tiny portion of users, we're seeing that hdiutil reports that it failed to attach the disk image. For the even tinier portion of users from whom we have obtained debug logs, one of the errors we've seen is "not recognized"; however, I don't know if that's the most common error, due to the small sample size. Before I get much further, I think it's prudent to acknowledge that the above system we're using today is pushing a decade old now, and it's probably wise to verify the foundations. So... For a Developer-ID-signed macOS app that is distributed outside the Mac App Store using an installer package, what is the "best" container/packaging system for an automated system to obtain and consume the installer package with the goal of a user-initiated self-update? For example: Notarized disk image (and failures to attach the image need to be bug reports to Apple) Just the installer package (If I understand correctly, this is bad because it bypasses the automatic propagation (normally performed by macOS) of the DMG's notary ticket to the pkg, right?) Something else? Secondly, what are some common developer mistakes to avoid? For example, these come to mind: When saving the DMG to disk, explicitly enable quarantine on the DMG, so that macOS runs appropriate security checks as intended (is this correct?) When running the installer package, do not use low-level tools (like cp) to copy the pkg out of the DMG, because macOS won't be able to automatically find the notary ticket when the pkg is installed (is this correct?) Anything else? Additional context: We currently support macOS 10.13+, but we will soon support only macOS 10.15+. Thank you!

I got the python app notarized and downloaded it fine. However, if you are caught by Gatekeeper and open the information window, you will see a lock and even if you enter the password to open the lock, it will not work. xattr -d com.apple.quarantine ./test.app You have to exclude it from the gatekeeper directly. I wonder if the downloaded app is unavoidable... or if there is another way.

Hi, we have an app that has been in development since Catalina and ever since Sonoma came out we noticed that when executing our pkg installer the application is installed correctly but the postinstall script is not executed. The weird thing is that if I run the pkg for the first time the postinstall does not execute BUT if I run it again then it DOES!! Looking through the logs I found these ones that confirm the execution of the script is being blocked. We haven't changed anything in the way we build the installer so I'm not quite sure how to fix this. 2024-04-25 16:29:51.570662-0300 0x1c62 Error 0x0 308 0 syspolicyd: [com.apple.syspolicy.exec:default] Unable (errno: 2) to read file at <private> for pid: 784 process path: <private> library path: (null) 2024-04-25 16:29:51.570662-0300 0x1c62 Error 0x0 308 0 syspolicyd: [com.apple.syspolicy.exec:default] Terminating process due to Malware rejection: 784, <private> 2024-04-25 16:29:51.570679-0300 0x1d13 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Sleep interrupted, signal 0x100 2024-04-25 16:29:51.570682-0300 0x1d13 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 784, /private/tmp/PKInstallSandbox.m5Av3O/Scripts/com.mycompany.myapp.pkg.BSOjtt/postinstall The app as well as the installer are both signed, notarized and stapled. Here you can see the script which just simply executes the app. #!/bin/bash echo "Running postinstall" /Applications/myapp.app/Contents/MacOS/myapp --load-system-extension & exit 0 Any help would be much appreciated. Thanks!

I have an installation workflow that works by a user double clicking on the mpkg and going through the prompts to install some software. Within the postinstall of the mpkg, /usr/sbin/installer -pkg "path_to_pkg" -target / is done to install additional software. The software contained in the mpkg contains system extensions and installs without issue. The software contained in the pkg file also contains system extensions and a prompt with this message displayed. "XSoftware" is damaged and can't be opened. You should move it to the Trash This file was downloaded on an unknown date. This is causing issues with the system extension being installed from XSoftware. Curiously enough, when I run /usr/sbin/installer -pkg "path_to_pkg" -target / manually in a terminal window it works successfully and XSoftware is able to install the System Extensions and run properly. I've used the pkgutil --check-signature to check the notarization and signing and it looks correct. This is my dmg structure: dmg | mpkg data_folder | pkg Any suggestions or help would be greatly appreciated. I can provide more details if neccessary.

Hi everyone, Has this every happened to you? If so, how did you resolve it? Submitting my app for review, I got the following rejection: Guideline 2.4.5(ii) - Performance The package currently available in App Store Connect cannot be installed and may be corrupted. Next Steps Please rebuild your application and upload a new version. If this issue continues, please contact Apple Developer Technical Support for help investigating the issue. DTS referred me back to app review: We are unable to help you resolve this matter. Please circle back with the App Review team for assistance. I'm building the .pkg with productbuild: xcrun productbuild --product WFH\ Phone\ Webcam.app/Contents/Info.plist --component WFH\ Phone\ Webcam.app /Applications --sign "3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U)" --timestamp WFH\ Phone\ Webcam.pkg and uploading it with altool: xcrun altool --username "..." --password "..." --validate-app --file WFH\ Phone\ Webcam.pkg --type osx xcrun altool --username "..." --password "..." --upload-app --file WFH\ Phone\ Webcam.pkg --type osx The .pkg signature looks fine: xcrun pkgutil --check-signature WFH\ Phone\ Webcam.pkg Package "WFH Phone Webcam.pkg": Status: signed by a developer certificate issued by Apple (Development) Signed with a trusted timestamp on: 2024-04-29 14:11:27 +0000 Certificate Chain: 1. 3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U) Expires: 2025-03-13 20:11:55 +0000 SHA256 Fingerprint: CB 8A 12 1D 4D 16 29 27 08 30 07 1C 6C F6 1C F4 85 6E AE F1 B1 34 68 F7 81 6D C3 3B 1B 8C 5D 32 ------------------------------------------------------------------------ 2. Apple Worldwide Developer Relations Certification Authority Expires: 2030-02-20 00:00:00 +0000 SHA256 Fingerprint: DC F2 18 78 C7 7F 41 98 E4 B4 61 4F 03 D6 96 D8 9C 66 C6 60 08 D4 24 4E 1B 99 16 1A AC 91 60 1F ------------------------------------------------------------------------ 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 SHA256 Fingerprint: B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C 68 C5 BE 91 B5 A1 10 01 F0 24 The app's signature also checks out: codesign --strict --deep --verbose --verify WFH\ Phone\ Webcam.app WFH Phone Webcam.app: valid on disk WFH Phone Webcam.app: satisfies its Designated Requirement I have no idea what "cannot be installed and may be corrupted" means and app review is not responding to my request for more information...

Hi, We have an app that installs a number of system extensions. According to this documentation the app must be located in the Applications folder to be activated so when the app launches we check that it is running from /Applications (or a subfolder) and if it isn't we inform the user and exit. This has been working fine until a recent submission whereupon installing the app via TestFlight casuses it to be translocated when run and our check to fail. So, a couple of questions: Is it expected that an app installed via TestFlight (or indeed the AppStore) can be translocated when it is run? If yes to the above, how can we ensure that out app is running from Applications and can therefore activate its extensions? Thanks Alan

I distribute an application in a zip file from my website. the application needs access to some files next to it to run properly. The application is correctly signed and notarized and stapled.Of course if I download it from my website, it gets the quarantine attribute. When I try to open it for the first time, a gatekeeper warning saying that the application comes from the internet, but has been checked by apple and no malware has been detected is displayed. My impression is that the application has been correctly signed and notarized. but If confirm that I wan to open it, the quarantine attribute is not deleted. spctl -a -v /path/to/Myapp.app path/to/Myapp.app: accepted source=Notarized Developer ID

I have an non-appstore application, using developer id which I want to transfer to another developer account. How can I go about doing this? How do I transfer the app ID? Will past versions of that app signed with the old account continue to work? Will I have to re-sign them?

I have two apps written in MAUI Mac Catalyst Framework -- one is main app, second is app updater. My updater works this way: it is located in the same directory as main app: firstly it deletes MainApp.app/Contents folder, then unzips new Contents folder that was downloaded from server. I added NSUpdateSecurityPolicy dictionary as in https://developer.apple.com/documentation/bundleresources/information_property_list/nsupdatesecuritypolicy and create application like . It looks that I wrote everything fine pkgbuild --install-location '/Library/Application Support/First' --root root --ownership preserve # aslo signing, etc But on user's macOS, system does not allow to delete Contents folder: I have IO_Access denied exception. Can it be because main app is sandboxing or something else? What I can do wrong? Thanks a lot in advance!

I am not enrolled in the Apple developer program and need to create a small Safari app extension helper that will be shared with my colleagues within the company. Is it somehow possible for me to distribute the app in some way without forcing everyone to disable a gatekeeper?

I have two apps that installed by .pkg . They are both signed by Developer Application . One of my apps has purpose of updating another app. It is implemented by deleteting it from folder, and unzipping archive with new .app to it's folder. Even if new app is signed and notarized, has stepled ticket on it, I get error "App is damaged and can't be opened". In Secrity and Confidentiality preferences I have warning that developer is unauthorized, even if this new app is notarized and signed. How can I implement app update to not throw error that app is damaged> Thanks a lot in advance

We have developed an application in which we have a main application and there are several loadable bundles which are loaded from within the main application. We archive the main application and generate the .app file. When we run the app, everything works fine and it loads the bundles. But when notarise the main application, it stops loading the bundles. We think we will need to notarise the bundles as well but not able to find the ways to do it. Any help will be very appreciated.

Could someone let me know if it is possible to create a self-signed Developer ID Installer certificate? Create an installer package using this certificate. And share it with others. This is just to do a simple proof of concept.

Hello, I'm keeping on getting a failure when trying to install an App from Samsung Dex. The report says to "disconnect your phone to install" but NO phone is connected. I tried various command line and numerous troubleshooting to reset and refresh some KEXT but still issue exists. Here is the install.log below. What could be the work around this bug? How to reset and proceed with installation? Thank you p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 16.0px 'Helvetica Neue'; color: #262626; -webkit-text-stroke: #262626; background-color: #ffffff} span.s1 {font-kerning: none} 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: @(#)PROGRAM:Install  PROJECT:Install-1000 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: @(#)PROGRAM:Installer  PROJECT:Installer-1020 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Hardware: iMac18,2 @ 3.00 GHz (x 4), 32768 MB RAM 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Running OS Build: macOS 11.4 (20F71) 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: USER=KP 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: __CFBundleIdentifier=com.apple.installer 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: COMMAND_MODE=unix2003 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: LOGNAME=KP 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: PATH=/usr/bin:/bin:/usr/sbin:/sbin 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.LsIZhGSQv0/Listeners 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: SHELL=/bin/zsh 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: HOME=/Users/KP 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: TMPDIR=/var/folders/d_/hqzchb455m9ct55v66n3n2_w0000gn/T/ 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: XPC_SERVICE_NAME=application.com.apple.installer.1152921500312163432.1152921500312163437 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Env: XPC_FLAGS=0x0 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Samsung DeX  Installation Log 2021-07-08 19:33:08-04 KPs-iMac Installer[9137]: Opened from: /Volumes/Samsung DeX/Install Samsung DeX.pkg 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Package Authoring Error: <background_scaling> has an unsupported MIME type: X-NSObject/NSNumber 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Package Authoring Error: <background_alignment> has an unsupported MIME type: X-NSObject/NSNumber 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Package Authoring Error: has an unsupported MIME type: X-NSObject/NSNumber 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Failed to load specified background image 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Product archive /Volumes/Samsung DeX/Install Samsung DeX.pkg trustLevel=350 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: External component packages (2) trustLevel=350 2021-07-08 19:33:09-04 KPs-iMac Installer[9137]: Could not load resource readme: (null) 2021-07-08 19:33:16-04 KPs-iMac Installer[9137]: Installation checks failed. 2021-07-08 19:33:16-04 KPs-iMac Installer[9137]: Installation check failure.  . Disconnect your phone to install..

I am working on an open source app. I have been testing the package installer, and something unexpected is happening: the .pkg won't run on my test machine and will instead show a banner saying "myApp.app can't be opened because Apple cannot check it for malicious software"; nevertheless, if I wait some minutes, the installer will run just fine! After reading through many of ekimo's posts, I assumed it may have something to do with stapler. I was not stapling my .dmg originally, so that's something I may be missing (my app is installed by a .pkg inside a .dmg). Nevertheless, the computer where I am testing the app has internet connection, meaning stapler should not even come into play. Regardless, I decided to staple my .dmg. Running xcrun stapler staple -v myApp.dmg after notarizing produces this result: builder ~ % xcrun stapler staple -v /Users/builder/Data/HEAD/installation/Packages/myApp.dmg Processing: /Users/builder/Data/HEAD/installation/Packages/myApp.dmg Properties are { NSURLIsDirectoryKey = 0; NSURLIsPackageKey = 0; NSURLIsSymbolicLinkKey = 0; NSURLLocalizedTypeDescriptionKey = "Disk Image"; NSURLTypeIdentifierKey = "com.apple.disk-image-udif"; "_NSURLIsApplicationKey" = 0; } Creating synthetic cdHash for unsigned disk image, myApp.dmg. Humanity must endure. Signing information is { cdhashes = ( {length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c} ); "cdhashes-full" = { 2 = {length = 32, bytes = 0xdd018313 b1c574a4 03f01dcc c96c2170 ... 918d33f3 d5a74dc3 }; }; cms = {length = 0, bytes = 0x}; "digest-algorithm" = 2; "digest-algorithms" = ( 2 ); flags = 2; format = "disk image"; identifier = ADHOC; "main-executable" = "file:///Users/builder/Data/HEAD/installation/Packages/myApp.dmg"; source = "explicit detached"; unique = {length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c}; } Stored Codesign length: 12 number of blobs: 0 Total Length: 12 Found blobs: 0 JSON Data is { records = ( { recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c"; } ); } Headers: { "Content-Type" = "application/json"; } Domain is api.apple-cloudkit.com Response is <NSHTTPURLResponse: 0x600003b85ba0> { URL: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup } { Status Code: 200, Headers { Connection = ( "keep-alive" ); "Content-Encoding" = ( gzip ); "Content-Type" = ( "application/json; charset=UTF-8" ); Date = ( "Mon, 26 Feb 2024 15:34:15 GMT" ); Server = ( "AppleHttpServer/78689afb4479" ); "Strict-Transport-Security" = ( "max-age=31536000; includeSubDomains;" ); "Transfer-Encoding" = ( Identity ); Via = ( "xrail:st53p00ic-qujn15041902.me.com:8301:24R11:grp60,631194250daa17e24277dea86cf30319:59e17ac665e1de7388b8f4e69e92e383:defra2" ); "X-Apple-CloudKit-Version" = ( "1.0" ); "X-Apple-Edge-Response-Time" = ( 99 ); "X-Apple-Request-UUID" = ( "9fc0fe2d-49fd-4e74-b718-660c56edb3bb" ); "X-Responding-Instance" = ( "ckdatabasews:16306401:st42p63ic-ztfb05112901:8807:2409B432:afc827b7b1ebf24829e9c4856d4b69205f23804f" ); "access-control-expose-headers" = ( "X-Apple-Request-UUID,X-Responding-Instance,Via" ); "x-apple-user-partition" = ( 63 ); } } Size of data is 165 JSON Response is: { records = ( { reason = "Record not found"; recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c"; serverErrorCode = "NOT_FOUND"; } ); } CloudKit query for myApp.dmg (2/dd018313b1c574a403f01dccc96c21705987d76c) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/dd018313b1c574a403f01dccc96c21705987d76c The staple and validate action failed! Error 65 What does this show? Thank you.

I've been trying to submit an application made with the Electron framework (electronjs.org) to the Mac Apple Store, but when launched an alert dialog appears with the text: "App Name Helper (Renderer)" differs from previously opened versions. Are you sure you want to open it? Opening "App Name Helper (Renderer)" will allow it to access data from previously used versions of "App Name Helper (Renderer)". ...this is preventing my Mac App Store submission. I've looked at troubleshooting information related to Gatekeeper and entitlements, etc. but I have not been able to determine which Apple subsystem (App Sandbox? Gatekeeper?) this particular alert comes from so I can possibly carve out an exception for it, or otherwise figure out how to fix it. "App Name Helper (Renderer)" is an agent process. Checking the App Store build results in: > spctl -a -t exec -vvv App\ Name.app/Contents/Frameworks/App\ Name\ Helper\ \(Renderer\).app App Name.app/Contents/Frameworks/App Name Helper (Renderer).app: rejected origin=Apple Distribution: Kevin Hughes (MYTEAMID) ...for App Store submission, is it expected that all agent processes should be signed with the Apple Distribution certificate? And is it OK that nothing is notarized before submission? If everything should be notarized, which certificate should be used? Does the App Store verification process check for this kind of thing regarding agent processes? Should it? Note that I can build, install, launch, and fully execute an Apple Developer ID-signed and notarized binary with a hardened runtime (and Apple Development profile) myself on my local machine as well as other macOS Sonoma 14.3.1 systems without any issues. The entitlements for my App Store build are: <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.assets.movies.read-only</key> <true/> <key>com.apple.security.assets.music.read-only</key> <true/> <key>com.apple.security.assets.pictures.read-only</key> <true/> <key>com.apple.security.automation.apple-events</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> <key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.debugger</key> <true/> <key>com.apple.security.cs.disable-executable-page-protection</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.files.downloads.read-only</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> <key>com.apple.security.network.client</key> <true/>

I support Mac code signing and notarisation for DTS and, as part of that work, I often need to look inside various Apple-specific archive file formats. This post explains how I do this. It’s mostly for the benefit of Future Quinn™, but I figured other folks would appreciate it as well. IMPORTANT This post explains low-level techniques for inspecting archives. Do not use them to create archives. Instead, create your archives using the highest-level tool that will get the job done [1]. Flat Installer Package A flat installer package — appropriate for uploading to the Mac App Store or the notary service — is actually a xar archive. Unpack it using the xar tool. For example: % # List the contents: % % xar -tf InstallTest-1.0d1.pkg com.example.apple-samplecode.InstallTest.pkg com.example.apple-samplecode.InstallTest.pkg/Bom com.example.apple-samplecode.InstallTest.pkg/Payload com.example.apple-samplecode.InstallTest.pkg/PackageInfo Distribution % % # Actually unpack: # % mkdir tmp % cd tmp % xar -xf ../InstallTest-1.0d1.pkg % find . . ./Distribution ./com.example.apple-samplecode.InstallTest.pkg ./com.example.apple-samplecode.InstallTest.pkg/Bom ./com.example.apple-samplecode.InstallTest.pkg/Payload ./com.example.apple-samplecode.InstallTest.pkg/PackageInfo See the xar man page for more info on that tool. The resulting Bom file is a ‘bill of materials’. For more on this, see the bom man page for details. Use lsbom to dump this: % lsbom ./com.example.apple-samplecode.InstallTest.pkg/Bom . 0 0/0 ./InstallTest.app … ./InstallTest.app/Contents … ./InstallTest.app/Contents/Info.plist … ./InstallTest.app/Contents/MacOS … ./InstallTest.app/Contents/MacOS/InstallTest … … The Payload file contains… you guessed it… the installer’s payload. This is a gzipped cpio archive. To unpack it, pipe the file through cpio: % cpio -i < com.example.apple-samplecode.InstallTest.pkg/Payload 5072 blocks % find InstallTest.app InstallTest.app InstallTest.app/Contents InstallTest.app/Contents/Info.plist InstallTest.app/Contents/MacOS InstallTest.app/Contents/MacOS/InstallTest … See the cpio man page for more info on that tool. Note This is a bit of a hassle so most of the time I use a third-party app to unpack installer packages. Which one? Well, I can’t give away all my secrets (-: Xip Archives To extract a xip archive (pronounced, I believe, as chip archive), run the xip tool with the --expand argument: % xip --expand XipTest.xip However, if that doesn’t work you’ll need to dig into the archive. First, undo the outer xar wrapper: % xar -xf XipTest.xip This produces two files, Content and Metadata: % ls -l total 7552 -rw-r--r-- 1 quinn staff 1683391 10 Jun 17:05 Content -rw-r--r-- 1 quinn staff 287 10 Jun 17:08 Metadata -rw-r--r-- 1 quinn staff 1697157 10 Jun 17:05 XipTest.xip The Metadata file is an XML property list: % cat Metadata … <dict> <key>UncompressedSize</key> <integer>2598653</integer> <key>Version</key> <integer>1</integer> </dict> </plist> The Content file is an Apple Archive. Unpack this using the aa tool: % aa extract -ignore-eperm -i Content -d tmp % find tmp tmp tmp/XipTest tmp/XipTest/XipTest.app tmp/XipTest/XipTest.app/Contents tmp/XipTest/XipTest.app/Contents/Info.plist tmp/XipTest/XipTest.app/Contents/MacOS tmp/XipTest/XipTest.app/Contents/MacOS/QCodeIndex tmp/XipTest/XipTest.app/Contents/MacOS/XipTest … See the aa man page for more info on that tool. Note aa was previously known as yaa. iOS App Archives iOS apps are stored in an .ipa file. This is actually a zip archive under the covers. To unpack it, change the file name extension to .zip and then double click it it in the Finder (or use your favourite unzipping tool, like unzip or ditto). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For installer package specifically, productbuild is your friend, but you can also use the lower-level tools like productsign, pkgbuild, and pkgutil. Revision History 2024-02-20 Added the iOS App Archives section. Added a note about third-party apps to the end of the Flat Installer Package section. 2022-09-30 Changed yaa to aa and added a reference to the Apple Archive framework. 2021-02-26 Fixed the formatting. 2020-06-10 First posted.

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 Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) IMPORTANT Most developers never see a code signing crash because they use Xcode to build and sign their product. Xcode’s code signing infrastructure detects problems that could cause a code signing crash, and its automatic code signing fixes them for you! If you’re having problems with code signing crashes and you can use Xcode but aren’t, consider making the switch Xcode. The most common code signing crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available If you see valid thread backtraces this is not a crash on launch. Go back to Resolving Trusted Execution Problems and read through the Code Signing Crashes After Launch section. If you see no thread backtraces, your code didn’t run at all. The trusted execution system has blocked it. In most cases there is some evidence of the problem in the system log. For example: type: error time: 2022-05-19 06:29:17.640331 -0700 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.OverClaim: Unsatisfied entitlements: com.apple.overclaim This indicates that the OverClaim app, with bundle ID com.example.apple-samplecode.OverClaim, claimed a restricted entitlement, com.apple.overclaim, that wasn’t authorised by a provisioning profile. For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. Specifically, the Entitlements on macOS section discusses the concept of restricted entitlements. For general information about the system log, see Your Friend the System Log. Normalise the Entitlements Property List Entitlement property list files look like text and so it’s tempting to edit them with a text editor. This can lead to all sorts of problems. If you have code whose entitlements property list contains comments, non-Unix line endings, or other weird formatting, the trusted execution system may block it. To avoid such problems, normalise your entitlements property list before passing it to codesign. For example: % plutil -convert xml1 MyApp.plist % codesign -s III --entitlements MyApp.plist MyApp.app Problems like this typically show up on older systems. Modern systems use DER-encoded entitlements, as discussed in The future is DER section of TN3125. A related gotcha is line breaks. Consider this entitlements property list file: % cat MyApp.plist … <plist version="1.0"> <dict> <key> com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist> This is a valid property list but it doesn’t do what you think it does. It looks like it claims the com.apple.security.cs.disable-library-validation entitlement but in reality it claims \ncom.apple.security.cs.disable-library-validation. The system treats the latter as a restricted entitlement and thus requires it to be authorised by a profile. Of course no such profile will authorise that entitlement, and so the app is blocked by the trusted execution system. Similarly, consider this: % cat MyApp.plist … <plist version="1.0"> <dict> <key> com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist> This claims com.apple.security.cs.disable-library-validation, note the leading space, and that’s also blocked by the trusted execution system. Check for Unauthorised Entitlements Sometimes the system log may not make it obvious what’s gone wrong. It may be easier to work this out by looking at the built program. The most common cause of problems like this is the app claiming a restricted entitlement that’s not authorised by a provisioning profile. To start your investigation, dump the entitlements to check for restricted entitlements: % codesign -d --entitlements - "OverClaim.app" …/OverClaim.app/Contents/MacOS/OverClaim [Dict] [Key] com.apple.application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.OverClaim [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] com.apple.overclaim [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true In this case all the entitlements except com.apple.security.get-task-allow are restricted. Note If there are no restricted entitlements, something else has gone wrong. Go back to Resolving Trusted Execution Problems and look for other potential causes. Now check that the provisioning profile was embedded correctly and extract its payload: % ls -l "OverClaim.app/Contents/embedded.provisionprofile" … OverClaim.app/Contents/embedded.provisionprofile % security cms -D -i "OverClaim.app/Contents/embedded.provisionprofile" -o "OverClaim-payload.plist" Check that the profile applies to this app by dumping the com.apple.application-identifier entitlement authorised by the profile: % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.application-identifier" OverClaim-payload.plist SKMME9E2Y8.com.example.apple-samplecode.* This should match the com.apple.application-identifier entitlement claimed by the app. Repeat this for all the remaining restricted entitlements: % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.developer.team-identifier" OverClaim-payload.plist SKMME9E2Y8 % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.overclaim" OverClaim-payload.plist Print: Entry, ":Entitlements:com.apple.overclaim", Does Not Exist In this example the problem is the com.apple.overclaim entitlement, which is claimed by the app but not authorised by the profile. If that’s the case for your program, you have two choices: If you program doesn’t need this entitlement, update your code signing to not claim it. If you program relies on this entitlement, update your profile to authorise it. The entitlement allowlist in the profile is built by the Apple Developer website based on the capabilities enabled on your App ID. To change this allowlist, modify your App ID capabilities and rebuild your profile. Some capabilities are only available on some platforms and, within that platform, for some distribution channels. For these details for macOS, see Developer Account Help > Reference > Supported capabilities (macOS). Some capabilities require review and approval by Apple. For more on this, see Developer Account Help > Reference > Provisioning with capabilities. Check for Required Entitlements If your app claims any restricted entitlements, it must also claim the com.apple.application-identifier entitlement, with its value being your app’s App ID. macOS uses this value to confirm that the embedded provisioning profile is appropriate for your app. Without this, macOS might not use this profile, which means there’s nothing to authorise your app’s use of restricted entitlements, which prevents your app from launching. IMPORTANT macOS 12 and later will use an embedded provisioning profile even if the app doesn’t claim the com.apple.application-identifier entitlement. So, if your app works on macOS 12 and later but fails on macOS 11, this is likely the cause. If you claim the com.apple.application-identifier entitlement then I recommend that you also claim the com.apple.developer.team-identifier entitlement. That’s what Xcode does, and my experience is that it’s best to stay on that well-trodden path. Check the Signing Certificate If your program’s entitlements look good, the next most likely problem is that your program was signed by a signing identity whose certificate is not authorised by the profile. To debug this, first extract the certificate chain from your program: % codesign -d --extract-certificates=signed-with- "OverClaim.app" … % for i in signed-with-* ; do mv "${i}" "${i}.cer" ; done The first certificate is the one that matters: % certtool d "signed-with-0.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Subject Name : Other name : UT376R4K29 Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … Now check this against each of the certificates authorised by the profile. Start by extracting the first one: % plutil -extract DeveloperCertificates.0 raw -o - OverClaim-payload.plist | base64 -D > "authorised0.cer" % certtool d "authorised0.cer" Serial Number : 46 A8 EF 2C 52 54 DE FD D1 76 9D 3A 41 7C 9E 43 … Subject Name : Other name : UT376R4K29 Common Name : Mac Developer: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … That’s not a match. So try the next one: % plutil -extract DeveloperCertificates.1 raw -o - OverClaim-payload.plist | base64 -D > authorised1.cer % certtool d "authorised1.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Subject Name : Other name : UT376R4K29 Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … This matches, which means the profile applies to this code. IMPORTANT When checking for a match, look at the Serial Number field. Don’t just rely on the Common Name field. A common mistake is to have two signing identities whose certificates have identical common names but the profile only lists one of them. If you get to the end of the list of certificate list in the profile and don’t find the certificate that the program was signed with, you know what the problem is: Your program is signed with a signing identity whose certificate is not listed in its profile. To fix this, either: Reconfigure your code signing to use a signing identity whose certificate is listed. Or update the profile to include the certificate of the signing identity you’re using. Check for Expiration If your certificates aren’t the problem, check that nothing has expired. Start with the certificate from the app’s signature: % certtool d "signed-with-0.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Not Before : 10:52:56 Apr 21, 2022 Not After : 10:52:55 Apr 21, 2023 … Also check the expiry date on the profile: % plutil -extract ExpirationDate raw -o - OverClaim-payload.plist 2023-04-21T11:02:58Z If either has expired, update it and re-sign your product. IMPORTANT Developer ID-signed code and installers include a secure timestamp. When the system checks the expiry date on a Developer ID certificate, it only checks that the certificate was valid at the time that the code was signed, base on that secure timestamp. Thus, an old Developer ID-signed app will continue to run after it’s certificate has expired. To learn more about secure timestamps, see TN3161 Inside Code Signing: Certificates. Check the Supported Devices If everything else checks out, the last thing to check is that the profile authorises the code to run on this machine. There are two cases here: Developer ID profiles authorise the code on all machines. Other profiles authorise the code on a specific list of machines. If you think you have a Developer ID profile, confirm that by looking for the ProvisionsAllDevices property: % plutil -extract "ProvisionsAllDevices" xml1 -o - "OverClaim-payload.plist" … No value at that key path or invalid key path: ProvisionsAllDevices If that’s not the case, get the ProvisionedDevices property and verify that the current machine’s provisioning UDID is listed there: % plutil -extract "ProvisionedDevices" xml1 -o - "OverClaim-payload.plist" … <array> … <string>A545CA26-80D7-5B38-A98C-530A798BE342</string> … </array> </plist> % system_profiler SPHardwareDataType … Provisioning UDID: A545CA26-80D7-5B38-A98C-530A798BE342 … If you get to the end any everything looks OK, your provisioning profile is not the cause of this crash. Return to Resolving Trusted Execution Problems for more suggestions. Revision History 2024-02-20 Added the Check for Required Entitlements section. Added a link to TN3161. Fixed the Developer Account Help links. 2022-06-08 Added the Normalise the Entitlements Property List section. 2022-05-20 First posted.

IMPORTANT I’m very pleased to report that, due to the hard work of a number of folks at Apple, this DevForums post has been replaced by official documentation: Packaging Mac software for distribution. I’m leaving this post in place as a historical curiosity, but please consult the official documentation going forward. This post is one of a pair of posts, the other one being Creating Distribution-Signed Code for Mac, that replaces my earlier Signing a Mac Product For Distribution post. For more background on this, see the notes at the top of Creating Distribution-Signed Code for Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Packaging Mac Software for Distribution Build a zip archive, disk image, or installer package for distributing your Mac software. Overview Xcode is a great tool for creating and distributing Mac apps. Once you’ve written your code you can upload it to the App Store with just a few clicks. However, Xcode cannot do everything. For example: Some Mac software products are not apps. You might, for example, be creating a product that includes a daemon. Some Mac products include multiple components. Your daemon might include an app to configure it. Some Mac products ship outside of the App Store, and so need to be packaged for distribution. For example, you might choose to distribute your daemon and its configuration app in an installer package. Some Mac products are built with third-party developer tools. If your product cannot be built and distributed using Xcode alone, follow these instructions to package it for distribution. Note If you use a third-party developer tool to build your app, consult its documentation for advice specific to that tool. To start this process you need distribution-signed code. For detailed advice on how to create distribution-signed code, see Creating Distribution-Signed Code for Mac. If you ship your product frequently, create a script to automate the distribution process. Decide on a Container Format To get started, decide on your container format. Mac products support two distribution channels: The Mac App Store, for apps Independent distribution, for apps and non-apps, using Developer ID signing A Mac App Store app must be submitted as an installer package. In contrast, products distributed outside of the Mac App Store use a variety of different container formats, the most common being: Zip archive (.zip) Disk image (.dmg) Installer package (.pkg) You may choose to nest these containers. For example, you might ship an app inside an installer package on a disk image. Nesting containers is straightforward: Just work from the inside out, following the instructions for each container at each step. IMPORTANT Sign your code and each nested container (if the container supports signing). For example, if you ship an app inside an installer package on a disk image, sign the app, then create the installer package, then sign that package, then create the disk image, then sign the disk image. Each container format has its own pros and cons, so choose an approach based on the requirements of your product. Build a Zip Archive If you choose to distribute your product in a zip archive, use the ditto tool to create that archive: Create a directory that holds everything you want to distribute. Run the ditto tool as shown below, where DDD is the path to the directory from step 1 and ZZZ is the path where ditto creates the zip archive. % ditto -c -k --keepParent DDD ZZZ Zip archives cannot be signed, although their contents can be. Build an Installer Package If you choose to distribute your product in an installer package, start by determining your installer signing identity. Choose the right identity for your distribution channel: If you’re distributing an app on the Mac App Store, use a Mac Installer Distribution signing identity. This is named 3rd Party Mac Developer Installer: TTT, where TTT identifies your team. If you’re distributing a product independently, use a Developer ID Installer signing identity. This is named Developer ID Installer: TTT, where TTT identifies your team. For information on how to set up these installer signing identities, see Developer Account Help. Run the following command to confirm that your installer signing identity is present and correct: % security find-identity -v 1) 6210ECCC616B6A72F238DE6FDDFDA1A06DEFF9FB "3rd Party Mac Developer Installer: …" 2) C32E0E68CE92936D5532E21BAAD8CFF4A6D9BAA1 "Developer ID Installer: …" 2 valid identities found The -v argument filters for valid identities only. If the installer signing identity you need is not listed, see Developer Account Help. IMPORTANT Do not use the -p codesigning option to filter for code signing identities. Installer signing identities are different from code signing identities and the -p codesigning option filters them out. If your product consists of a single app, use the productbuild tool to create a simple installer package for it: % productbuild --sign III --component AAA /Applications PPP In this command: III is your installer signing identity. AAA is the path to your app. PPP is the path where productbuild creates the installer package. The above is the simplest possible use of productbuild. If you’re submitting an app to the Mac App Store, that’s all you need. If you have a more complex product, you’ll need a more complex installer package. For more details on how to work with installer packages, see the man pages for productbuild, productsign, pkgbuild, and pkgutil. For instructions on how to read a man page, see Reading UNIX Manual Pages. Build a Disk Image If you choose to distribute your product in a disk image: Create a directory to act as the source for the root directory of your disk image’s volume. Populate that directory with the items you want to distribute. If you’re automating this, use ditto rather than cp because ditto preserves symlinks. Use hdiutil command shown below to create the disk image, where SSS is the directory from step 1 and DDD is the path where hdiutil creates the disk image. Decide on a code signing identifier for this disk image. If you were signing bundled code, you’d use the bundle ID as the code signing identifier. However, disk images have no bundle ID and thus you must choose a code signing identifier for your image. For advice on how to do this, see the Sign Each Code section in Creating Distribution-Signed Code for Mac. Use the codesign command shown below to sign the disk image, where III is your Developer ID Application code signing identity (named Developer ID Application: TTT, where TTT identifies your team), BBB is the code signing identifier you chose in the previous step, and DDD is the path to the disk image from step 3. % hdiutil create -srcFolder SSS -o DDD % codesign -s III --timestamp -i BBB DDD For more information on code signing identities, see the Confirm Your Code Signing section in Creating Distribution-Signed Code for Mac. IMPORTANT Sign your disk image with a code signing identity, not an installer signing identity. There are various third-party tools that configure a disk image for distribution. For example, the tool might arrange the icons nicely, set a background image, and add a symlink to the Applications folder. If you use such a tool, or create your own tool for this, make sure that the resulting disk image: Is signed with your Developer ID Application code signing identity Is a UDIF-format read-only zip-compressed disk image (type UDZO) Submit Your App to the Mac App Store If you’re creating an app for the Mac App Store, submit your signed installer package using either the altool command-line tool or the Transporter app. For detailed instructions, see App Store Connect Help > Reference > Upload tools. Notarize Your Product If you’re distributing outside of the Mac App Store, notarize the file you intend to distribute to your users. For detailed instructions, see Customizing the Notarization Workflow. Skip the Export a Package for Notarization section because you already have the file that you want to submit. If you’re using nested containers, only notarize the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarize the disk image. The exception to this rule is if you have a custom third-party installer. In that case, see the discussion in Customizing the Notarization Workflow. Staple Your Product Once you’ve notarized your product, staple the resulting ticket to the file you intend to distribute. Staple the Ticket to Your Distribution discusses how to do this for an app within a zip archive. The other common container formats, installer packages and disk images, support stapling directly. For example, to staple a tick to a disk image: % xcrun stapler staple FlyingAnimals.dmg Stapling is recommended but not mandatory. However, if you don’t staple a user might find that your product is blocked by Gatekeeper if they try to install or use it while the Mac is offline. Revision History 2024-02-19 Added a preamble that links to the official documentation, Packaging Mac software for distribution. 2022-03-01 First posted.