Notarization

RSS for tag

Notarization is the process of scanning Developer ID-signed software for malicious components before distribution outside of the Mac App Store.

Notarization Documentation

Pinned Posts

Posts under Notarization tag

109 Posts
Sort by:
Post marked as Apple Recommended
10k Views
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.
Posted
by
Post not yet marked as solved
11 Replies
5.4k Views
This is a solved problem, but a detail not in any docs I could find and I could only get answered from support. Figured I'd add it to the index.App-specific passwords are not supported with Managed Apple ID created through Business Manager. You will simply not see the option to create an app-specific password even if you do have two-factor authentication turned on.
Posted
by
Post not yet marked as solved
13 Replies
2.9k Views
Since upgrading to Xcode 12.5, attempting to submit an app for notarization with /usr/bin/xcrun altool --notarize-app has started failing ~10% of the time with the error Upload succeeded but did not receive a RequestUUID.. Has anyone else encountered this issue? ?xml version="1.0" encoding="UTF-8"? !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" plist version="1.0" dict keyos-version/key string11.2.0/string keyproduct-errors/key array dict keycode/key integer-1018/integer keymessage/key stringUpload succeeded but did not receive a RequestUUID./string keyuserInfo/key dict keyNSLocalizedDescription/key stringUpload succeeded but did not receive a RequestUUID./string keyNSLocalizedFailureReason/key stringUnable to upload your app for notarization./string /dict /dict /array keytool-path/key string/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/Frameworks/AppStoreService.framework/string keytool-version/key string4.050.1210/string /dict /plist
Posted
by
Post not yet marked as solved
7 Replies
3.9k Views
Hi everyone, I'm struggling to access a certificate stored in keychain when using LaunchDaemons and would appreciate any advise to improve over my current workaround with an agent. I'm maintaining an M1-based Mac Mini with macOS Big Sur 11.4 as a build client for Gitlab CI. The machine makes itself known to the orchestrating Gitlab server through the so-called gitlab-runner process which regularly polls the Giltab server for build job requests. It would then eventually call xcodebuild to generate artifacts and upload them to Gitlab. In order to have this process startup automatically, I've loaded it through a /Library/LaunchDaemons/gitlab-runner.plist file in launchctl. This setup has been working greatly for months, making the build client immediately available after a reboot without the need to log into it. I've now started to deploy codesign tasks to the build client and encountered issues with keychain access to the certificate. I installed the certificate and performed security find-identity -v -p codesigning in the Terminal to validate correct installation. I have ensured that the codesign tasks succeed when performed through Terminal manually. A popup was shown on first try about codesign wanting to access to the local keychain, which I always allowed. Codesign then reported success: signed Mach-O universal. The behavior is different for my LaunchDaemons-based codesign tasks (spawned under the same user). I've tried multiple permutations for sudo launchctl load -w /Library/LaunchDaemons/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=true, System keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: FAIL (error: The specified item could not be found in the keychain.) SessionCreate=false, System keychain: FAIL (errSecInternalComponent) I've then tried a user agent launchctl load -w ~/Library/LaunchAgents/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: OK (Popup -> Always allow, signed Mach-O universal) So apparently, the last variant works reliably. However, it has the severe downside that I now need to log in the user after a reboot in order to kick off the agent. Is there a way to make this work with /Library/LaunchDaemons, possibly through some plist property? As a test I've tried to "Allow all applications" to access the private key associated with the Certificate but that didn't change anything. Best regards Maik
Posted
by
Post not yet marked as solved
10 Replies
4.3k Views
Just got my brand new M1 Max laptop and am excited to get with the times and use notary tool instead of altool as recommended by the mothership but when I try to notarize the same file that altool notarizes successfully it fails. Here is is my sucessful altool command: xcrun altool --notarize-app --primary-bundle-id "My Kool Tool" --username "***@***.com" -p "@keychain:ac_notary" --asc-provider XXXXXXXXXXXX --file *.zip && rm *.zip and this is the notary tool command that fails on the same file: xcrun notarytool submit *.zip --keychain-profile "XXXXXX Apple Developer" --wait && rm *.zip Here is the output: Conducting pre-submission checks for archive.zip and initiating connection to the Apple notary service... Submission ID received  id: e20c0438-5576-4361-a11a-2efeb8exxxxx Successfully uploaded file  id: e20c0438-5576-4361-a11a-2efeb8exxxxx  path: /Users/***/Documents/archive.zip Waiting for processing to complete. Current status: Invalid.......... Processing complete  id: e20c0438-5576-4361-a11a-2efeb8exxxxx  status: Invalid and the log: xcrun notarytool log e20c0438-5576-4361-a11a-2efeb8exxxxx --keychain-profile "XXXXXX Apple Developer" {  "logFormatVersion": 1,  "jobId": "e20c0438-5576-4361-a11a-2efeb8exxxxx",  "status": "Invalid",  "statusSummary": "Archive contains critical validation errors",  "statusCode": 4000,  "archiveFilename": "archive.zip",  "uploadDate": "2021-12-07T18:57:23.193Z",  "sha256": "505d76b420d46bfd01d56c724de1c8d20121d75b0ca6cee96a51549708ec46ee",  "ticketContents": null,  "issues": [   {    "severity": "error",    "code": null,    "path": "archive.zip",    "message": "Package archive.zip has no signed executables or bundles. No tickets can be generated.",    "docUrl": null,    "architecture": null   }  ] } again, the same file notarizes with altool so it is properly signed It is worth noting that if I don't include the --asc-provider in the altool command it fails so maybe I just need to do the same with the notary tool but can't find any documentation on how to do that. Help Obi Wan
Posted
by
Post not yet marked as solved
0 Replies
5.6k Views
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 Mac DevForums post Packaging Mac Software for Distribution DevForums post Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey 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 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-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.
Posted
by
Post not yet marked as solved
0 Replies
3k Views
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.
Posted
by
Post not yet marked as solved
0 Replies
1.7k Views
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.
Posted
by
Post marked as solved
15 Replies
3.6k Views
Hi! Trying to use notarytool for an app notarization via script on CD pipeline. Build machine has an Xcode 12.5 installed and currently it can't be upgraded. So, our team decided to use utility as standalone binary, placed in the /Applications directory. The command used for notarization: '/Applications/notarytool submit '<path>' --keychain-profile '<profile-name>' --output-format 'json' --wait'. Before running the command above, we saved keychain profile with notarytool store-credentials command. However, future runs of notarization script fail with a message: 'Error: No Keychain password item found for profile: '. But we definitely see it among Keychain entries and 'security find-generic-password -l ' command approves that profile has been saved. Did anyone encounter a similar issue? Can someone suggest what how to cope with this behavior? Thank you in advance for any ideas
Posted
by
Post not yet marked as solved
4 Replies
2.2k Views
Hi, I have a problem with replacing altool to notarytool to notarize my app for distribution outside AppStore. Earlier I used this code (-p passes App's password): xcrun altool --notarize-app --primary-bundle-id "MyProductBundleID" -u "myname@gmail.com" -p "wxxx-xxxx-xxxx-xxxx" --file MyProduct.zip I wrote a new script: xcrun notarytool submit MyProduct.zip --keychain-profile "wxxx-xxxx-xxxx-xxxx" --wait Error with unknown "--keychain-profile".
Posted
by
Post not yet marked as solved
6 Replies
1.1k Views
I am making the switch from altool to notarytool and I've run into a brick wall trying to submit our app zip. It is created using ditto -c -k --keepParent "path-to-app" "path-to-zip" On submission I get: Error: <app-name>.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg) Absolutely baffled by this.
Posted
by
Post not yet marked as solved
3 Replies
1.1k Views
i have success fully archived the code. when trying to publish the app in app store. clicking on distribute button from archives am getting this error. "Distribution of "App name" requires the "iPhoneOS" platform to be installed. Please install the required platform to distribute "App Name."" please help as to fix this.
Posted
by
Post not yet marked as solved
2 Replies
1k Views
When altool notarizes my apps, I get an email confirmation to my Apple ID email address. This does not happen with notarytool. Is this expected behavior?
Posted
by
Post marked as solved
8 Replies
2.4k Views
I made a project with GameMaker and exported it to Xcode, then I archived it and tried to Distribute App with DeveloprID. So when I try to upload my build to apple notary service (Distribute app in Xcode), I get the following error message: "Distribution failed with errors: Couldn't communicate with a helper application. Try your operation again. If that fails, quit and relaunch the application and try again." This just happened out of nowhere without me having done any changes on my Mac (not changing the project file, not updating GameMaker, MacOS or Xcode because they are already the latest version, just nothing). A few days before that I tried to upload the same project which worked, but it didn't get "ready to distibute" status yet. Because it was stil in "processing" after a few days I tried to upload the same project again (and I tried uploading new empty projects as well) and every time I get "upload failed" status now. Using MacOS (13.1) and Xcode 14.2, GameMaker 2022.11.1.156/2022.11.1.175 and latest Beta, I tried restarting Mac and all programs, re-installing Xcode, and exporting a new project
Posted
by
Post marked as solved
3 Replies
1.7k Views
Hi everyone, I'm trying to use the Notary Service using xcrun notarytool. As part of that process I want to store the credentials using xcrun notarytool store-credentials. When entering the correct credentials, I receive following error: Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct. I am using Xcode 14.2 (14C18). Output from running the command with the --verbose argument: [13:12:09.377Z] Debug [MAIN] Running notarytool version: 1.0.0 (27), date: 2023-03-03T13:12:09Z, 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: <profile-name> 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: <apple-id> App-specific password for <apple-id>: Developer Team ID: <team-id> Validating your credentials... [13:12:39.468Z] Info [API] Initialized Notary API with base URL: https://appstoreconnect.apple.com/notary/v2/ [13:12:39.469Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/test?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [13:12:39.470Z] Debug [AUTHENTICATION] Delaying current request to refresh app-specific password token. [13:12:39.470Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/asp?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [13:12:39.471Z] Debug [AUTHENTICATION] Authenticating request to '/notary/v2/asp' with Basic Auth. Username: <apple-id>, Password: private<String>, Team ID: <team-id> [13:12:39.472Z] Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls. [13:12:44.032Z] Debug [API] Received response status code: 401, message: unauthorized, URL: https://appstoreconnect.apple.com/notary/v2/asp?, Correlation Key: 7DPE2ASCQ7LLQ2FL4QANKNEBHI [13:12:44.033Z] Error [TASKMANAGER] Completed Task with ID 2 has encountered an error. [13:12:44.033Z] Debug [TASKMANAGER] Ending Task Manager loop. Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct. What can I do to fix this issue?
Posted
by
Post marked as solved
6 Replies
1.3k Views
We're in the process of updating an app that we released approximately a year ago -- which had no issues with codesigning and notarization in our last release. The current version fails at the initial submission process; stating that the file "must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)" The process itself we're taking is rather straightforward, and follows much of what I've seen repeated on the forums here. A few additional details: The app itself (a Unity project with a lot of content that needs to be shipped with the app) is quite large, weighing in at around 20GB. Despite this large size, we were able to go through this process in the past with no issues. I was originally running Xcode 13 on Big Sur, but upgraded to Xcode 14 on Ventura to no avail. Our notarization script runs the following: ditto -c -k --keepParent OurAppName.app NotarizationFileName.zip xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait When we add --verbose to the xcrun command; this is our output: $ Build > xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose [23:01:54.643Z] Debug [MAIN] Running notarytool version: 1.0.0 (27), date: 2023-03-25T23:01:54Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose Conducting pre-submission checks for NotarizationFileName.zip and initiating connection to the Apple notary service... [23:01:54.717Z] Info [PREFLIGHT] NotarizationFileName.zip is not a zip archive. warning [/Users/michael/.jenkins/workspace/bastion-add-build-tools/Build/NotarizationFileName.zip]: 17179869184 extra bytes at beginning or within zipfile (attempting to process anyway) . Err: 1 [23:01:54.729Z] Debug [PREFLIGHT] NotarizationFileName.zip did not pass the disk image potentiality test. Moving on to other tests. [23:01:54.730Z] Debug [PREFLIGHT] NotarizationFileName.zip is not a flat installer package. [23:01:54.731Z] Debug [PREFLIGHT] Finished completing determination of file type for NotarizationFileName.zip. Operation took 80ms. Error: NotarizationFileName.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg) Usage: notarytool <subcommand> See 'notarytool --help' for more information.
Posted
by
Post not yet marked as solved
5 Replies
876 Views
Have had a Mac app request for notarization today with Status: in progress for nearly 7 hours now. Still waiting. This is using the same process we have been using successfully for several years and last time was just last week. Looking for info if there is a known delay or other reason for this?
Posted
by
Post not yet marked as solved
3 Replies
1.1k Views
I am trying to submit my AppleScript applet for notarization. My applet is code signed using my developer id. I have stored an app-specific password in my logins keychain with the correct name and account. My developer id is not connected with multiple teams. I tried this on the command line: xcrun notarytool submit "/Users/[home]/Desktop/[applet].zip" --keychain-profile "[name]" --wait The response, very quickly, was: "Error: No Keychain password item found for profile: [name]". Is something else needed to enable notarytool to find the Keychain login item ? Thanks.
Posted
by