General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums 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 forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums 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"

I am experiencing a persistent issue when trying to sign my application, PhotoKiosk.app, using codesign. The process consistently fails with the error errSecInternalComponent, and my troubleshooting indicates the problem is with how the system accesses or validates my certificate's trust chain, rather than the certificate itself. Error Details and Configuration: codesign command executed: codesign --force --verbose --options=runtime --entitlements /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/entitlements.plist --sign "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/dist/PhotoKiosk.app Error message received: Warning: unable to build chain to self-signed root for signer "(null)" /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/dist/PhotoKiosk.app: errSecInternalComponent Diagnostic Tests and Verifications Performed: Code Signing Identity Validation: I ran the command security find-identity -v -p codesigning, which successfully confirmed the presence and validity of my certificate in the Keychain. The command output correctly lists my identity: D8FB11D4C14FEC9BF17E699E833B23980AF7E64F "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" This suggests that the certificate and its associated private key are present and functional for the system. Keychain Certificate Verification: The "Apple Root CA - G3 Root" certificate is present in the System Roots keychain. The "Apple Worldwide Developer Relations Certification Authority (G6)" certificate is present and shown as valid. The trust setting for my "Developer ID Application" certificate is set to "Use System Defaults". Attempted Certificate Export via security: To further diagnose the problem, I attempted to export the certificate using the security find-certificate command with the exact name of my identity. Command executed (using double quotes): security find-certificate -c -p "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" > mycert.pem Error message: security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain. The same error occurred when I tried with single quotes. This result is contradictory to the output of find-identity, which successfully located the certificate. This suggests an internal inconsistency in the Keychain database, where the certificate is recognized as a valid signing identity but cannot be located via a simple certificate search. Additional Troubleshooting Attempts: I have already recreated the "Developer ID Application" certificate 4 times (I am at the limit of 5), and the issue persists with all of them. The application has been rebuilt, and the codesign command was run on a clean binary. Conclusion: The problem appears to be an internal macOS failure to build the trust chain for the certificate, as indicated by the errSecInternalComponent error. Although the certificate is present and recognized as a valid signing identity by find-identity, the codesign tool cannot complete the signature. The failure to find the certificate with find-certificate further supports the suspicion of an inconsistency within the keychain system that goes beyond a simple certificate configuration issue. I would appreciate any guidance on how to resolve this, especially given that I am at my developer certificate limit and cannot simply generate a new one.

Submissions stuck for ovwe 2 hours: 812e835c-6215-44ef-b052-030f8a4ef1cd 1bae8357-7b2e-450d-bde8-87e48a02c1a1 680d3c51-3316-43b3-a50d-ec0b444f183a Is there a service issue? Normal processing time exceeded.

Whilst waiting for the company developer account I successfully notarised an app/pkg On switching to the company account the app/pkg has been stuck in progress for over 2 days (see below) The initial submission was via Xcode and later via command line. The last one was when I updated bundle ids etc and built with Github Actions. The initial submission did coincide with a service outage, however that is marked as resolved. I would like to cancel all of them now that I have switched the signing account and the bundle ID but there seems no way to do this? Thoughts and comments welcome. Thanks Paul -------------------------------------------------- createdDate: 2025-08-14T11:03:24.837Z id: edf215d0-4d15-4075-aa6f-4755a35b3d45 name: ZenityEndpointAgent.pkg status: In Progress -------------------------------------------------- createdDate: 2025-08-12T21:36:36.345Z id: 9c98de09-d3aa-449b-ad47-7e721b0342c5 name: AIEdgeDeviceAgent.pkg status: In Progress -------------------------------------------------- createdDate: 2025-08-12T16:58:50.891Z id: 9206f9be-0fc4-4c6c-aa66-8fcbe3332155 name: AIEdgeDeviceAgent.pkg status: In Progress -------------------------------------------------- createdDate: 2025-08-12T10:37:35.624Z id: b20d1dd0-084e-441c-87a6-641fb088819e name: AIEdge Device Agent.zip status: In Progress

I am building an electron app bundled with python. My code signing was fast, but when it came to notarization, it has already taken over 6+ hours. How can I speed things up?

We distribute our macOS products as a PKG downloaded from our website. To simplify configuration for our customers, we create a PKG for each customer that contains identifying data for that customer. We are currently doing this by notarizing the PKG for each customer and uploading the result. Since we sometimes exceed the notarization limit of 75/day, we began investigating other ways of including the identifying data. One avenue seemed to be the extended attribute com.apple.application-instance, but after experimentation it appears that this attribute does not persist through downloads. There are very few resources describing this attribute (TN2206) but a close reading seems to confirm that the attribute has to be set on the user’s machine. Can you confirm that this is the case? Is there any other way for customizing an installer PKG that won’t run afoul of notarization limits?

Hello, I'm currently trying to upload a new version of an existing application. But each time I try to validate the archive of the application, I got the following error in Xcode (v16.2) : Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “37CG5MY799.com.example.app” value for the com.apple.application-identifier key in “com.example.app.pkg/Payload/app.app/Contents/MacOS/app” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. I suspect that there is a problem with the App ID Prefix (that is 37CG5MY799 for the app) when our team ID is E4R7RJ7LA3 but I cannot find a solution. I asked the Apple Developer Support for help and I have read the documentation they sent but it couldn't solve this problem so they redirected me to the forums. https://developer.apple.com/library/archive/qa/qa1879/_index.html https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-OVERVIEW https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG33 There isn't any obvious App ID Prefix mismatch in the entitlement between the Application's signature entitlement and the Embedded provisioning profile entitlement . Application's signature entitlement : <dict> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> Embedded provisioning profile entitlement : <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> <string>E4R7RJ7LA3.*</string> </array> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>keychain-access-groups</key> <array> <string>37CG5MY799.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> </dict> The app also have a browser extension that correctly use the Team ID. How to solve this problem ? Thanks for your time, Qeg

Hello Apple Support, While attempting to staple a notarization ticket for our signed installer package, the stapler command fails with Error 65. Upon investigation, we found that connections to oscdn.apple.com present an SSL certificate issued to a248.e.akamai.net, which does not include oscdn.apple.com in its Subject Alternative Name (SAN). This mismatch prevents our macOS environment from validating tickets and completing the stapling process. Steps tried: Verified notarization status (Accepted). DNS flushed, tried different DNS (8.8.8.8, 1.1.1.1). curl to oscdn.apple.com consistently fails with SSL error 60. Please advise on resolving this certificate mismatch. also when I try to run the stapler command with my pkg "xcrun stapler staple/Users/mactest/Desktop/IPMPlus_Macos_Installer.signed.pkg" getting the output like :- Processing: /Users/mactest/Desktop/IPMPlus_Macos_Installer.signed.pkg Could not validate ticket for /Users/mac-test/Desktop/IPMPlus_Macos_Installer.signed.pkg The staple and validate action failed! Error 65. please help Thank you.

Its just stuck in progress. $ xcrun notarytool history --keychain-profile X Successfully received submission history. history -------------------------------------------------- createdDate: 2025-07-21T16:46:13.233Z id: X name: X.dmg status: In Progress -------------------------------------------------- createdDate: 2025-07-20T18:44:35.683Z id: X name: X.dmg status: In Progress -------------------------------------------------- createdDate: 2025-07-20T11:24:20.319Z id: X name: X.dmg status: In Progress Its a go app; not simple but not very complicated. It is my first time notarising but even then should it take this long?? 3 days is ridiculous!

I’m facing an issue with my macOS app after code signing and notarization. The app is signed with my Developer ID and notarized using xcrun notarytool. Everything works fine on the machine where the signing was done — Gatekeeper accepts it, no warning appears, and codesign/spctl checks pass. However, when running the same .app on other Macs, users receive a Gatekeeper warning saying the app is "malicious software and cannot be opened". The signature is valid and the notarization log shows status: Accepted. What I've tried: Verified signature with codesign --verify --deep --strict --verbose=2 Checked notarization status via xcrun notarytool log Assessed Gatekeeper trust with spctl --assess --type execute Everything passes successfully on the development machine. Why would the app be treated as malicious on other systems even after notarization? I'm happy to share logs and technical details if needed.

We're interested in adopting App Sandbox in an app distributed outside of the Mac App Store. However, we're hitting a bit of a roadblock and it doesn't seem like either of the techniques described in that post can be used in a reasonable way. For background, this is a third-party launcher for a cross-platform Java game that, among other things, makes it easier for users to mod the game. Users generally download mods as .jar files and place them in a certain directory. In some cases, these mods contain native dynamic libraries (e.g. a .dylib) as part of their code. In general, the .dylib is extracted from the contents of the .jar to some temporary location, loaded, and then deleted once the game closes (the exact details, like the actual temporary location, depends on the mod). App Sandbox greatly interests us in this case because it can limit the damage that a compromised mod could do, and in my testing the functionality of most mods still works with it enabled. However, sandboxed apps quarantine every file they write to by default. Unfortunately, most mods are created by individual developers who don't notarize their libraries (their mods are generally cross-platform, and they're likely just using third-party code that they bundle with the mod but don't sign or notarize). [1] This means that a mod that loads a dynamic library as described above triggers Gatekeeper as described in the documentation if the app is sandboxed, but does not if the sandbox is disabled. Even worse, a user often can't bypass the warning even if they trust the mod because the extracted library is usually a temporary file, and generally is deleted after the failure (which usually causes the game to crash and thus close). By the time they try to approve the code in System Settings, the file is gone (and even if they could approve it, this approval wouldn't stick next time they launch the game). In theory it would work to use an unsandboxed XPC service to remove the quarantine and let the libraries through. However, this is easier said than done. We don't control the mods' code or how they go about loading whatever code they need, which limits what we can do. [1] And in some cases, people like to play old versions of the game with old mods, and the versions they're using might've been released before notarization was even a thing. The closest thing I can think of to a solution is injecting code into the Java process that runs code to call out to the XPC service to remove the quarantine before a library loads (e.g. before any calls to dlopen using dyld interposition). A prototype I have... works... but this seems really flimsy, I've read that interposition isn't meant to be used in non-dev tools, and if there's a better solution I'd certainly prefer that over this. Other things we've tried have significant downsides: com.apple.security.files.user-selected.executable requires user selection in a file picker, and seems to be more blunt than just allowing libraries/plugins which might lead to a sandbox escape [2] Adding the app to the "Developer Tools" section in System Settings > Privacy & Security allows the libraries to load automatically, but requires users to add the app manually and also sounds like it would make a sandbox escape very easy [2] Oh, and I also submitted an enhancement request for an entitlement/similar that would allow these libraries to load (FB13795828) but it was returned as "no plans to address" (which honestly wasn't that surprising). [2] My understanding is that if a sandboxed process loads libraries, the library code would still be confined by the sandbox because it's still running in the sandboxed process. But if a sandboxed process can write and open a non-quarantined app, that app would not be within the confines of the sandbox. So basically we want to somehow allow the libraries to load but not allow standalone executables to run outside the sandbox. In general the game and almost all popular mods I've tested work with App Sandbox enabled, except for this Gatekeeper snag. It would be a shame to completely abandon App Sandbox for this reason if everything else can be made to work. This situation seems not super common, but documentation does say When your sandboxed app launches for the first time, macOS creates a sandbox container on the file system (in ~/Library/Containers) and associates it with your app. Your app has full read and write access to its sandbox container, and can run programs located there as well. which leaves me wondering whether the Gatekeeper prompt is even intended behavior since the libraries are in the sandbox container and written by the app. (By the way, my testing of the claim that apps can run programs in their sandbox container didn't seem to confirm what the documentation said, even without quarantine - FB15963761). Though, given the other documentation page I linked above which more directly references Gatekeeper and quarantined plug-ins, I doubt this is a bug. I suppose the final question is, is this just a situation where App Sandbox won't work (at least in any supported way)? Or is there perhaps some technique we're missing?

Hi guys, New to publishing apps on Apple Store. I encounter some notarization error before and resolved it in this post. By solving the previous issue, I updated the Trust setting from "Always Trust" to "Use System Defaults" for Apple certificates. The codesign and notarization no longer give me any problem. But now, I encountered another issue. When I ran the .app on my local Macbook, it now gives me "zsh: trace trap" error. Dive a little further and check the crash report, I found the some details as following. Process: my_app [30652] Path: /Users/USER/my_app_path Identifier: my_app Version: 0.0.0 (???) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-07-15 14:57:58.9874 -0400 OS Version: macOS 15.5 (24F74) Report Version: 12 Anonymous UUID: 2335F0B6-A26E-6446-6074-0FCE620C4B6A Time Awake Since Boot: 6000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Exception Codes: UNKNOWN_0x32 at 0x00000001064b4000 Exception Codes: 0x0000000000000032, 0x00000001064b4000 Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page VM Region Info: 0x1064b4000 is in 0x1064b4000-0x1064b8000; bytes after start: 0 bytes before end: 16383 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 1064ac000-1064b4000 [ 32K] r-x/rwx SM=COW Object_id=d2a02fbf ---> VM_ALLOCATE 1064b4000-1064b8000 [ 16K] r-x/rwx SM=PRV __TEXT 1064b8000-1068a4000 [ 4016K] r-x/rwx SM=COW my_app.app/Contents/Frameworks/Python.framework/Versions/3.12/Python I can tell it's about codesign and signature invalid. I have tried to rebuild, re-codesign and re-notarize. But the error still persists. Could someone help me? Thanks!

SMAppService Error 108 "Unable to read plist" on macOS 15 Sequoia - Comprehensive Test Case Summary We have a fully notarized SMAppService implementation that consistently fails with Error 108 "Unable to read plist" on macOS 15 Sequoia, despite meeting all documented requirements. After systematic testing including AI-assisted analysis, we've eliminated all common causes and created a comprehensive test case. Error: SMAppServiceErrorDomain Code=108 "Unable to read plist: com.keypath.helperpoc.helper" 📋 Complete Repository: https://github.com/malpern/privileged_helper_help What We've Systematically Verified ✅ Perfect bundle structure: Helper at Contents/MacOS/, plist at Contents/Library/LaunchDaemons/ Correct SMAuthorizedClients: Embedded in helper binary via CREATE_INFOPLIST_SECTION_IN_BINARY=YES Aligned identifiers: Main app, helper, and plist all use consistent naming Production signing: Developer ID certificates with full Apple notarization and stapling BundleProgram paths: Tested both Contents/MacOS/helperpoc-helper and simplified helperpoc-helper Entitlements: Tested with and without com.apple.developer.service-management.managed-by-main-app What Makes This Different Systematic methodology: Not a "help me debug" post - we've done comprehensive testing Expert validation: AI analysis helped eliminate logical hypotheses Reproduction case: Minimal project that demonstrates the issue consistently Complete documentation: All testing steps, configurations, and results documented Use Case Context We're building a keyboard remapper that integrates with https://github.com/jtroo/kanata and needs privileged daemon registration for system-wide keyboard event interception. Key Questions Does anyone have a working SMAppService implementation on macOS 15 Sequoia? Are there undocumented macOS 15 requirements we're missing? Is Error 108 a known issue with specific workarounds? Our hypothesis: This appears to be a macOS 15 system-level issue rather than configuration error, since our implementation meets all documented Apple requirements but fails consistently. Has anyone encountered similar SMAppService issues on macOS 15, or can confirm a working implementation?

Hi guys, I am new to publishing apps on Apple Store. I used python, pyside6, torch, pyinstaller to build an app for Apple Store. For codesigning, I used the correct "Developer ID Application" to sign the code. When I validate the .app file (codesign -vv --strict ), I got the following my_app.app: valid on disk my_app.app: satisfies its Designated Requirement Next, I used ditto to "ditto -c -k --sequesterRsrc --keepParent my_app.app my_app.zip" to zip it. Then, I submitted this my_app.zip file for notarization with "xcrun notarytool submit ..." and got the following "accepted" message. Received new status: Accepted Current status: Accepted............... [20:08:54.530Z] Info [API] Submission in terminal status: Accepted Processing complete After that, I want to staple it with "xcrun stapler staple my_app.app", but I got the following Could not validate ticket for my_app.app The staple and validate action failed! Error 65. To further investigate it, I ran "spctl -a -vvv my_app.app" and got my_app.app: rejected source=Unnotarized Developer ID origin=Developer ID Application... I don't know why this would happen after notarization accepted. Could someone help me understand this issue? Thanks!

I submitted a mac app for Notarization. For the first few tries the Notarization failed with an error "Team is not yet configured for Notarization" but few days after my account started to show "ENROLL" option again even though my membership was set to expire on 2026. I am doubting my account has been suspended. I have not received any emails from apple regarding the suspension. I have contacted support but no help yet ! This was the second year, i was paying for the membership. Could you please help me to - Help me get the account unsuspended (if it is, as there is no notification or information regarding this) If the account is suspended due to my app being submitted for Notarization then help me identify the reason so that i can fix them. Mac App is Time Tracking application that runs in background and capture periodic screenshot(NOTE - I am doing this after taking user consent)

I submitted a mac app for Notarization. For the first few tries the Notarization failed with an error "Team is not yet configured for Notarization" but few days after my account started to show "ENROLL" option again even though my membership was set to expire on 2026. I am doubting my account has been suspended. I have not received any emails from apple regarding the suspension. I have contacted support but no help yet ! This was the second year, i was paying for the membership. Could you please help me to - Help me get the account unsuspended (if it is, as there is no notification or information regarding this) If the account is suspended due to my app being submitted for Notarization then help me identify the reason so that i can fix them. Mac App is Time Tracking application that runs in background and capture periodic screenshot backlsh.com (NOTE - I am doing this after taking user consent)

I came across your contact on the Apple Developer Forums. I'm encountering an unusual issue during the notarization process. The error message states: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." Any guidance you could provide would be greatly appreciated. Here are the error details for reference: json { "logFormatVersion": 1, "jobId": "b6023a7c-dc85-4fa5-91dd-fba92c9ed831", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "Bytemonk.dmg", "uploadDate": "2025-07-02T07:07:07.945Z", "sha256": "b9494170cc040a76045ed263de22e6b89a5455142af16ce502530e1c1ee72ddf", "ticketContents": null, "issues": null }

Dear Apple Developer Technical Support, I am encountering an issue with notarizing and stapling both PKG and DMG installers for our Electron-based macOS application COSGrid. Despite receiving successful notarization submission responses via notarytool, the stapling process fails with Error 65. Environment: App Name: COSGrid Bundle Identifier: com.cosgrid.pkg.COSGrid Developer ID Team ID: YB8S2XZ98K macOS Version: macOS [15.1] Xcode Version: [16.0 (16A242d)] Workflow Summary: For PKG: Build via yarn build (Vite + Electron Builder) Package with pkgbuild Sign using productsign Submit for notarization: xcrun notarytool submit COSGridMZA-2.1.10-arm64.pkg --apple-id "..." --team-id YB8S2XZ98K --password "..." --wait Conducting pre-submission checks for COSGridMZA-2.1.10-arm64.pkg and initiating connection to the Apple notary service... Submission ID received id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a Upload progress: 100.00% (235 MB of 235 MB) Successfully uploaded file id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a path: /Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGridMZA-2.1.10-arm64.pkg Waiting for processing to complete. Current status: Accepted..................... Processing complete id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a status: Accepted Receive notarization success Stapling fails: xcrun stapler staple COSGridMZA-2.1.10-arm64.pkg Could not validate ticket... The staple and validate action failed! Error 65. For DMG: Sign via codesign Submit to notarization — success Attempt to staple: xcrun stapler staple -v COSGrid-2.1.10-arm64.dmg Could not validate ticket... The staple and validate action failed! Error 65. Additional Verification: I verified the DMG’s code signature integrity: Command: codesign --verify --verbose=4 COSGrid-2.1.10-arm64.dmg Output: COSGrid-2.1.10-arm64.dmg: valid on disk COSGrid-2.1.10-arm64.dmg: satisfies its Designated Requirement Command: codesign -dvv COSGrid-2.1.10-arm64.dmg Output: Executable=/Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGrid-2.1.10-arm64.dmg Identifier=COSGrid-2.1.10-arm64 Format=disk image CodeDirectory v=20200 size=308 flags=0x0(none) hashes=1+6 location=embedded Signature size=9013 Authority=Developer ID Application: COSGrid Systems Private Limited (YB8S2XZ98K) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=1 Jul 2025 at 11:34:05 AM Info.plist=not bound TeamIdentifier=YB8S2XZ98K Sealed Resources=none Internal requirements count=1 size=180 **Verified Signature for .pkg ** pkgutil --check-signature COSGridMZA-2.1.10-arm64.pkg Package "COSGridMZA-2.1.10-arm64.pkg": Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2025-06-30 13:57:19 +0000 Certificate Chain: 1. Developer ID Installer: COSGrid Systems Private Limited (teamID) Expires: 2027-02-01 22:12:15 +0000 2. Developer ID Certification Authority Expires: 2027-02-01 22:12:15 +0000 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 Diagnostic Logs Attached: Stapler verbose logs for both PKG and DMG codesign verification output for both PKG and DMG Notarytool submission logs Ticket JSON response from Apple API API request/response headers Effective electron-builder.yaml config Key Observations: codesign verification passes successfully for both artifacts Notarization submission reports success via notarytool Stapler fails with Error 65 for both PKG and DMG Ticket JSON fetched from CloudKit API appears valid No provisioning profile used (Developer ID distribution only) Request: Could you please help investigate: Why is the stapler unable to validate or attach the ticket even though notarization completes successfully? Are there any known issues, entitlements, or workflow adjustments recommended in this case? Is any special handling required for Electron apps’ PKG/DMG packages or Hardened Runtime configurations during stapling? I can provide the signed DMG/PKG and full notarization logs upon request. Thank you very much for your assistance — looking forward to your guidance. Best regards, Murugavel COSGrid Systems Private Limited

It's been over 24h and it's still in progress. Is there a timeout for a failed notarization? or do we just wait for days.. weeks.. moths? Successfully received submission info createdDate: 2025-06-25T09:52:03.153Z id: 2ae713a5-c2e3-432f-84ee-e5d3d4aed621 name: slideshow-city-1.1.0-arm64.dmg status: In Progress

Yesterday there were reported outages on the Developer ID Notary Service, but it was reported pretty late and we were able to notice the outages in real time. It says resolved now, however an error still persists: Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. Is there an ongoing outage at this moment that is not being reported again? Our pipelines have been working flawlessly for months without intervention nor changes until the most recent outages

Starting a few hours ago (roughly 2:45PM Eastern time) we began experiencing elevated latency with the Developer ID Notary Service. There is nothing listed on the developer system status page about degraded performance or a service outage. Operations that usually take ~15 minutes, are stacking up for hours. The oldest pending entry we have was created at 2:45PM Eastern: createdDate: 2025-06-24T18:45:22.539Z id: 5209a4d2-eae4-4714-aa8e-6961677ff2e We currently have 27 pending builds in the notary service since we are required to notarize internal builds to ensure we satisfy our requirements so this is creating an issue for us.