What is the proper process for notarizing an installer package? I have tried every permutation I can find and it always returns "The signature of the binary is invalid". It's a Qt6 app if that is relevant. I've bundled and signed the app using: macdeployqt myapp.app \ -always-overwrite -verbose=1 \ -hardened-runtime \ -sign-for-notarization=\"$${sign_name}\" \ It verifies OK codesign -v --verify --deep myapp.app myapp.app: valid on disk myapp.app: satisfies its Designated Requirement I have successfully notarized and stapled it: ... The staple and validate action worked! This is where I'm not sure of the proper process. I've used pkgbuild to put the app into .pkg file and successfully signed that using an Installer ID. pkgutil --check-signature myapp-signed.pkg Package "myapp-signed.pkg": Status: signed by a developer certificate issued by Apple for distribution ... On attempting to notarise this packge I get The signature of the binary is invalid for every shared library and the executable in the package. That error message is not very useful so how do I diagnose the issue? So far I've tried a few things I've found on the forum but the error is always the same unhelpful one.

I know I have to be doing something wrong. I've been trying notarize my app for a few days. I've bundled my app and am able to sign with hardened runtime. When I submit for notary with this command /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit /path/to/your/file.zip --wait --key "/path/to/your/AuthKey_ABCD1234.p8" --key-id "ABCD1234" --issuer "uuid-issuer-id" it just eventually times out with no feedback or error report.

We have developed a secure desktop app using QT, we are developing and delivering this app for more than 2 years. While deploying app we perform codesigning and notarization of app and we use Ventura on build system. So the issue we observed is that if we install this app on any macOS version below Sonoma it works as expected and in Apparency we can see code signature is verified and also app in notarized. But if we install the same app on Sonoma and check in Apparency, it shows signature can't be verified.

For reasons beyond the scope of this post, I need to build one of my products on macOS 10.14 I was using xcrun altool --notarize-app but it stopped working today (per the recent announcement that it was going away, so not a surprise) I am told that it is possible to run the notarytool on 10.14, i.e. xcrun notarytool, which is what I use for builds on newer platforms. I'm hoping that someone can help me to get a version of notarytool that will run on 10.14 Thanks in advance

Throws an eroor [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataChecksum = 62c853b5b00cf96f96576b4d48ce6d0a [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataCompressed = (suppressed) [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataInfo = {app_platform=osx, primary_bundle_identifier=ocean.drive.app, device_id=, bundle_identifier=, packageVersion=software5.9, apple_id=, asset_types=[developer-id-package], bundle_version=, bundle_short_version_string=} [2023-12-07 07:55:36 UZT] DBG-X: parameter OSIdentifier = Mac OS X 12.2.1 (x86_64); jvm=14.0.2+12-iTunesOpenJDK-8; jre=14.0.2+12-iTunesOpenJDK-8 [2023-12-07 07:55:36 UZT] DBG-X: parameter PackageName = 0b641208d73f17697b28370fa99ad8a7.itmsp [2023-12-07 07:55:36 UZT] DBG-X: parameter PackageSize = 228662271 [2023-12-07 07:55:36 UZT] DBG-X: parameter StatisticsClientStartDateTimeZoneISO = 2023-12-07T07:55:36+05:00 [2023-12-07 07:55:36 UZT] DBG-X: parameter TransporterArguments = -m upload -u @@@@ -vp json -DTxHeaders=eyJqZW5nYSI6dHJ1ZX0= -sessionid @env:8A006125-AC15-400B-9FC2-C4D609DB7FA1 -sharedsecret hidden value -itc_provider PROVIDER -f /var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/F75419E9-DDDB-4F74-BC71-B970FD924FB4/0b641208d73f17697b28370fa99ad8a7.itmsp -indicator true -v eXtreme -Dtransporter.client=altool -Dtransporter.client.version=5.329 (1309) [2023-12-07 07:55:36 UZT] DBG-X: parameter Version = 3.3.0 [2023-12-07 07:55:36 UZT] DBG-X: parameter iTMSTransporterMode = upload [2023-12-07 07:55:36 UZT] INFO: id = 20231207075536-140 [2023-12-07 07:55:36 UZT] INFO: iTMSTransporter Correlation Key: f33460ff-fc03-4158-bed2-b2e99ffd521c-0001 [2023-12-07 07:55:36 UZT] DEBUG: SMART-CLIENT: Host HTTP header: contentdelivery01.itunes.apple.com [2023-12-07 07:55:36 UZT] DBG-X: Apple's web service operation return value: [2023-12-07 07:55:36 UZT] DBG-X: parameter Errors = [Unable to process validateMetadata request at this time due to a general error (1019)] [2023-12-07 07:55:36 UZT] DBG-X: parameter RestartClient = false [2023-12-07 07:55:36 UZT] DBG-X: parameter ErrorCode = 1019 [2023-12-07 07:55:36 UZT] DBG-X: parameter ErrorMessage = Unable to process validateMetadata request at this time due to a general error (1019) [2023-12-07 07:55:36 UZT] DBG-X: parameter ShouldUseRESTAPIs = false [2023-12-07 07:55:36 UZT] DBG-X: parameter Success = false [2023-12-07 07:55:36 UZT] ERROR: Unable to process validateMetadata request at this time due to a general error (1019) [2023-12-07 07:55:36 UZT] DBG-X: The error code is: 1019 [2023-12-07 07:55:36 UZT] INFO: JSON:{"msg":{"phase":"Upload","count":2,"description":"Operation failed","index":2},"messageType":"VerifyProgress"} [2023-12-07 07:55:36 UZT] DBG-X: Returning 1 2023-12-07 07:55:36.750 Out: Package Summary: 1 package(s) were not uploaded because they had problems: /var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/F75419E9-DDDB-4F74-BC71-B970FD924FB4/0b641208d73f17697b28370fa99ad8a7.itmsp - Error Messages: Unable to process validateMetadata request at this time due to a general error (1019) 2023-12-07 07:55:36.797 *** Error: Notarization failed for '/var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/electron-notarize-LC5Kmm/OceanDrive.zip'. 2023-12-07 07:55:36.797 *** Error: Unable to process validateMetadata request at this time due to a general error (1019) (1019) 2023-12-07 07:55:36.797 *** Warning: altool has been deprecated for notarization and starting in late 2023 will no longer be supported by the Apple notary service. You should start using notarytool to notarize your software. (-1030)

Hi Guys, I am facing a problem I find difficult to debug. I had a company Apple ID, member of team, that I used for notaryzation of an app via: res=$(xcrun notarytool submit ${file_to_notarize} --apple-id stepan.svoboda@memsource.com --password ${password} --team-id PK8H4S4HPF --wait 2>&1) But I will be leaving the company soon so we created new apple ID. desktop@phrase.com We invited this ID to team. And assigned it admin role. I generated app specific password and I am using it with this new apple ID But then running: res=$(xcrun notarytool submit ${file_to_notarize} --apple-id desktop@phrase.com --password ${password} --team-id PK8H4S4HPF --wait 2>&1) Fails with: Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct. And I run out of ideas what to check, what could be wrong.

Hi! I'm having an issue notarizing my app. I've developed my app in python, packaged it with py2app and then codesigned it using command-line: codesign --deep --sign "Developer ID Application: Name (ID)" MyApp.app and verified it using: codesign --verify --verbose MyApp.app with no problem. I then continued to notarize it with notarytool: xcrun notarytool submit MyApp.zip --keychain-profile "MyProfile" --wait and everything went smoothly, however, the process ended as invalid. This is a recurring issue (used altool beforehand) where I get errors that prevent the notarization due to signature issues, some of them: "The signature of the binary is invalid." "The executable does not have the hardened runtime enabled." "The binary is not signed with a valid Developer ID certificate." "The signature does not include a secure timestamp." And so on. The issue is that this is occurring to the contents of the app and the python libraries and other dependencies it uses, not MyApp.app itself. I've read online in many places and couldn't find what am I missing, I've followed the code-signing and notarization instructions to no prevail. I hope someone here can help me solve this problem or figure out what am I missing. Many thanks :)

Hi, I want to use notarytool to let my installer *pkg being notarized by apple. The app is a swift desktop app, not supposed to be distributed through the app store. It is already signed and notarized through xcode. Verification done and it has been aproved. So the process should be working. I'm facing an issue when using notarytool to store cretentials. I followed the steps for described here https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow My app specific password I created here: https://appleid.apple.com/account/manage When I try to strore credentials I get a 401, what did I miss here? xcrun notarytool store-credentials --verbose [07:21:52.672Z] Debug [MAIN] Running notarytool version: 1.0.0 (32), date: 2023-12-01T07:21:52Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool store-credentials --verbose This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name. Profile name: notarytool-pw We recommend using App Store Connect API keys for authentication. If you'd like to authenticate with an Apple ID and app-specific password instead, leave this unspecified. Path to App Store Connect API private key: Switching prompts to app-specific password credentials. Developer Apple ID: <my developer Apple ID> App-specific password for <my developer Apple ID>: <the app specific password I created earlier> Developer Team ID: <my developer team ID> Validating your credentials... [07:31:40.888Z] Info [API] Initialized Notary API with base URL: https://appstoreconnect.apple.com/notary/v2/ [07:31:40.890Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/test?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [07:31:40.890Z] Debug [AUTHENTICATION] Delaying current request to refresh app-specific password token. [07:31:40.891Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/asp?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [07:31:40.891Z] Debug [AUTHENTICATION] Authenticating request to '/notary/v2/asp' with Basic Auth. Username: <my developer Apple ID>, Password: private<String>, Team ID: <my developer team ID> [07:31:40.892Z] Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls. [07:31:41.921Z] Debug [API] Received response status code: 401, message: unauthorized, URL: https://appstoreconnect.apple.com/notary/v2/asp?, Correlation Key: 6WYAHNFB6NYEVPPJOT5KJMNPAE [07:31:41.922Z] Error [TASKMANAGER] Completed Task with ID 2 has encountered an error. [07:31:41.922Z] Debug [TASKMANAGER] Ending Task Manager loop. Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct.

I've been trying to notarize an installer (.pkg file) on a new laptop. Previous versions have been notarized successfully on a previous Mac. However, in spite of having the required certificates (same as the old Mac, generated for the new Mac) the submission gets stuck at "In Progress". Doing it multiple times (even hours apart) doesn't help. Is there a FAQ / suggested list of steps to help resolve this issue? Here's what I see: xcrun notarytool history --keychain-profile "(my profile name)" results in (problem started with v4, the first version I've tried on this new Mac): createdDate: 2023-10-17T01:34:36.911Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-17T01:33:59.191Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T21:01:25.832Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T19:57:44.776Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-02T14:17:34.108Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v3.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-28T14:04:46.211Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v2.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-20T17:28:46.168Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v1.pkg status: Accepted -------------------------------------------------- xcrun notarytool log xxxxxxxxxxxxxxxxxxxx --keychain-profile "(my profile name)" results in: Submission log is not yet available or submissionId does not exist id: xxxxxxxxxxxxxxxxxxxxxxxx

I seems like a pretty common issue but i'll make a post about it specifically for what i'm seeing. Its my first time notarizing an app so maybe its something in my config, but i'm not seeing any errors. For simplicity I cloned, built and signed the sample Electron Forge app following the steps on https://www.electronforge.io/ "Getting Started". The build zip is 90MB so its not that large. My production application will be DMG, but even that is stuck (Maybe because the zips before it are currently stuck) Trying to manually notarize via notarytool just hangs. I used xcrun notarytool submit <Package> --keychain-profile "NotaryProfile" --wait Running xcrun notarytool history --keychain-profile "NotaryProfile" outputs the following. createdDate: 2023-09-06T14:49:59.810Z id: 838c0903-d136-4241-be98-174152a7e3cf name: my-new-app.zip status: In Progress -------------------------------------------------- createdDate: 2023-09-06T14:31:08.880Z id: 1ce6ef46-8b09-4b20-9f61-81292b2dcbb9 name: my-new-app.zip status: In Progress -------------------------------------------------- createdDate: 2023-09-06T14:10:23.726Z id: 71bc9206-036e-46c7-aadf-6bfaa4097743 name: my-new-app.zip status: In Progress -------------------------------------------------- createdDate: 2023-09-06T13:54:35.527Z id: 7c7fd365-1f08-48c6-a314-3a1809019f9c name: my-new-app.zip status: In Progress Its been about 7 hours since my first attempt. I tried to pull logs by calling xcrun notarytool log --keychain-profile "NotaryProfile" aa6e9df3-ef62-4058-8bcc-683f015b412a but it seems like non exist yet. Submission log is not yet available or submissionId does not exist id: aa6e9df3-ef62-4058-8bcc-683f015b412a Not sure whats going on, but its pretty far off from the time estimate of 5 - 45 minutes. Any help is appreciated. NotaryTool version is 1.0.0 (28)

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'm getting a "Couldn’t communicate with a helper application" error when uploading archive to notary service from Xcode. Xcode v14.2. MacOS 13.2.1. Tried booting from safe mode, re-installing Xcode, re-installing OS. Any ideas what could be causing this? Thanks :)

For a few days now, notarytool is crashing whenever I'm running one of my Jenkins jobs where notarytool is called from a shell script. Based on the debug log, the crash appears round at the time that the upload of the binary to be notarized is attempted. When a runloop should be started to run the upload via an async http request: Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls. The specific job setup looks like this: Jenkins Job › Run shell script phase › Shell script › Second shell script › notarytool call. Running the notarytool directly from Terminal works and completes as expected. Crashlog Snippet: Path: /Applications/Xcode-14.2.app/Contents/Developer/usr/bin/notarytool Identifier: notarytool Version: ??? Code Type: X86-64 (Native) Parent Process: launchd [1] Responsible: java [428] OS Version: macOS 12.6.2 (21G320) Crashed Thread: 1 Dispatch queue: com.apple.NSURLSession-work Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [18889] Application Specific Signatures: API Misuse Thread 1 Crashed:: Dispatch queue: com.apple.NSURLSession-work 0 libxpc.dylib 0x7ff81aa2720e _xpc_api_misuse + 117 1 libxpc.dylib 0x7ff81aa128bb xpc_connection_set_target_uid + 193 2 AppSSOCore 0x7ff8264facaa -[SOServiceConnection _connectToService] + 533 3 AppSSOCore 0x7ff8264faa6f -[SOServiceConnection initWithQueue:] + 102 4 AppSSOCore 0x7ff8264fa98a -[SOClient init] + 122 5 AppSSOCore 0x7ff8264fa855 -[SOConfigurationClient init] + 180 6 AppSSOCore 0x7ff8264fa78c __38+[SOConfigurationClient defaultClient]_block_invoke + 16 7 libdispatch.dylib 0x7ff81ab1c317 _dispatch_client_callout + 8 8 libdispatch.dylib 0x7ff81ab1d4fa _dispatch_once_callout + 20 9 AppSSOCore 0x7ff8264fa77a +[SOConfigurationClient defaultClient] + 117 10 AppSSOCore 0x7ff8264fa6af +[SOAuthorizationCore _canPerformAuthorizationWithURL:responseCode:callerBundleIdentifier:useInternalExtensions:] + 130 11 AppSSOCore 0x7ff8264f9df0 appSSO_willHandle + 64 Back in January the exact same setup was still working. Same macOS version. Xcode version might have been different. Would really appreciate some help since for now re-implementing notarytool appears to be the only solution.

2022-07-24 16:43:30.074 *** Error: Notarization failed for '/var/folders/r1/3j8rdbl95l9csz588j1nc6xc0000gn/T/electron-notarize-gGm3Fr/git-icons.zip'. 2022-07-24 16:43:30.075 *** Error: You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881 You do not have required contracts to perform an operation (-19208) { NSLocalizedDescription = "You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881"; NSLocalizedFailureReason = "You do not have required contracts to perform an operation"; }

IMPORTANT altool is deprecated for the purposes of notarisation and will stop working on 1 Nov 2023 [1]. If you’re currently notarising with altool, switch to notarytool now. For specific advice on how to do this, see TN3147 Migrating to the latest notarization tool. General: DevForums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log DevForums post Q&A with the Mac notary service team Developer > News post Notarisation and the macOS 10.9 SDK DevForums post Testing a Notarised Product DevForums post Notarisation Fundamentals DevForums post The Pros and Cons of Stapling DevForums post Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] See Apple notary service update.

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 four common Gatekeeper problems: App blocked by a dangling load command path Broken code signature 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. macOS 14 introduced gktool, a very minimal interface to Gatekeeper. Run the tool with the help argument to learn more: % gktool help Verify Your Signature A good first step in any Gatekeeper investigation is to verify that your code is signed correctly. Use the codesign tool for this: % codesign -v -vvv --strict --deep MyApp.app The -vvv options increase verbosity to the point where codesign will give you useful diagnostics. For example: % codesign -v -vvv --strict --deep "Munged.app" Munged.app: a sealed resource is missing or invalid file added: …/Munged.app/Contents/Resources/names/Adam.txt file modified: …/Munged.app/Contents/Resources/names/Morgan.txt file missing: …/Munged.app/Contents/Resources/names/Rhonda.txt This app was changed after it was signed in three different ways: Adam.txt was added. Morgan.txt was modified. Rhonda.txt was removed. You might see some results that make no sense. For example: Start with an app with a valid code signature: % codesign -v -vvv --strict --deep "NotNormal.app" NotNormal.app: valid on disk NotNormal.app: satisfies its Designated Requirement Use the Finder to create a zip archive (File > Compress). Use the Finder to unpack that archive. Check the code signature of the unpacked file: % codesign -v -vvv --strict --deep "NotNormal 2.app" NotNormal 2.app: a sealed resource is missing or invalid file added: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt file missing: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt There are two things to note here. First, just compressing and decompressing the app broke its code signature. Weird! Second, look at the error messages. It seems that the Zoë Schrödinger.txt file is was both added and removed. Weirder! To see what’s going on here you have to look at a hex dump of the file name: % ls "NotNormal.app/Contents/Resources/names" | xxd 00000000: 5a6f c3ab 2053 6368 726f cc88 6469 6e67 Zo.. Schro..ding 00000010: 6572 2e74 7874 0a er.txt. % ls "NotNormal 2.app/Contents/Resources/names" | xxd 00000000: 5a6f 65cc 8820 5363 6872 6fcc 8864 696e Zoe.. Schro..din 00000010: 6765 722e 7478 740a ger.txt. The names are not the same! The app started out with the ë in precomposed form and the ö in decomposed form. Compressing and decompressing the app converted the ë to its decomposed form, and that change broke the code signature. Programs that deal with Unicode are expected to ignore differences in normalisation. Sadly, Apple’s code signing implementation missed that memo (r. 68829319). For more details see this post but the executive summary is that it’s best to stick to ASCII when naming files in a bundle. Identify 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. Resolve 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. Revision History 2024-11-11 Added a mention of gktool. 2022-05-20 Added the Verify Your Signature section. Made other minor editorial changes.

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.

I help a lot of developers with macOS 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. IMPORTANT macOS 14 has a new tool, syspolicy_check, that was specifically designed to help diagnose problems like this. I plan to update this post once I have more experience with it. In the meantime, however, if you hit a trusted execution problem and it reproduces on macOS 14, please try out syspolicy_check and let us know how that pans out. 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 anti-malware 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 macOS Packaging Mac software for distribution 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 property. 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 curl or 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. A 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 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 You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 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.

It seems like something changed in the notarization in the last few days. I'm running the same build script that creates and notarize a DMG that contains a PKG with 4 plugins. Everything is signed correctly. No error anywhere in the notarization process. Checking the status of the notarization, I get this: Status: success Status Code: 0 Status Message: Package Approved Stapling returns this: The staple and validate action worked! Yet, if I check the PKG inside with this command: spctl -a -vvv -t install I get this output: .pkg: rejected source=Unnotarized Developer ID origin=Developer ID Installer: My Company This project was perfectly working a few weeks ago, and we have not changed a thing. Checking the notarization log, the only issue I see is this: "issues": [ { "severity": "warning", "code": null, "path": "Archive.dmg/Installer.pkg", "message": "This archive is corrupt, and cannot be unpacked for analysis.", "docUrl": null, "architecture": null } ] But this warning is also present in past DMG/PKG thatare notarized and work as they should. Another difference from previous logs is that I can only see one item in ticketContents, which is the DMG, while previously I could see two, both the DMG and the PKG.

I've tried to notarize my app recently and got the error:{ "logFormatVersion": 1, "jobId": "...", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization", "statusCode": 7000, "archiveFilename": "myapp.dmg", "uploadDate": "2019-06-20T06:24:53Z", "sha256": "...", "ticketContents": null, "issues": null }I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.