IMPORTANT The underlying issue here (FB8830007) was fixed in macOS 11.3, so the advice in this post is irrelevant if you’re building on that release or later.
Note This content is a repost of info from another thread because that thread is not world readable (it’s tied to the DTK programme).
A number of folks have reported problems where:
They have a product that supports older versions of macOS (anything prior to 10.11).
If they build their product on Intel, everything works.
If they build their product on Apple Silicon, it fails on those older versions of macOS.
A developer filed a bug about this (FB8830007) and, based on the diagnosis of that bug, I have some info to share as to what’s going wrong and how you can prevent it. Let’s start with some background.
macOS’s code signing architecture supports two different hash formats:
sha1, the original hash format, which is now deprecated
sha256, the new format, support for which was added in macOS 10.11
codesign should choose the signing format based on the deployment target:
If your deployment target is 10.11 or later, you get sha256.
If your deployment target is earlier, you get both sha1 and sha256.
This problem crops up because, when building for both Intel and Apple Silicon, your deployment targets are different. You might set the deployment target to 10.9 but, on Apple Silicon, that’s raised to the minimum Apple Silicon system, 11.0. So, which deployment target does it choose?
Well, the full answer to that is complex but the executive summary is that it chooses the deployment target of the current architecture, that is, Intel if you’re building on Intel and Apple Silicon if you’re building on Apple Silicon. For example:
intel% codesign -d --arch x86_64 -vvv Test664892.app
…
Hash choices=sha1,sha256
…
intel% codesign -d --arch arm64 -vvv Test664892.app
…
Hash choices=sha1,sha256
…
arm% codesign -d --arch x86_64 -vvv Test664892.app
…
Hash choices=sha256
…
arm% codesign -d --arch arm64 -vvv Test664892.app
…
Hash choices=sha256
…
The upshot is that you have problems if your deployment target is less than 10.11 and you sign on Apple Silicon. When you run on, say, macOS 10.10, the system looks for a sha1 hash, doesn’t find it, and complains.
The workaround is to supply the --digest-algorithm=sha1,sha256, which overrides the hash choice logic in codesign and causes it to include both hashes:
arm% codesign -s - --digest-algorithm=sha1,sha256 Test664892.app
arm% codesign -d --arch x86_64 -vvv Test664892.app
…
Hash choices=sha1,sha256
…
% codesign -d --arch arm64 -vvv Test664892.app
…
Hash choices=sha1,sha256
…
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Having reviewed every document, this has been going on for nearly two months. Originally, it was thought that the problem might be related to the fact I had created the developer ID signing certificate on an intel mac, and trying to import and use it on an M1 Mac-Mini. That turned out to not be the case. Completely started over with a new account (the company changed names), requested and was granted the entitlements we needed. Create a new CSR from this new m1 machine, created a Developer ID certificate, installed the certificate on this machine. But no matter what, the codesign fails.
Troubleshooting
Environment:
Brand new Apple Developer account and Developer ID Application certificate (generated CSR on this Mac, installed cert and private key in login keychain)
macOS build/signing machine, not running codesign as root
Working from Terminal app in GUI session, not via SSH/cron
Keychain & Certificate Chain:
Verified Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ) certificate and private key are present in login keychain
Verified certificate is marked as trusted and has a private key attached
Developer ID Certification Authority present and trusted in System keychain (removed any extra from login)
Evaluate certificate assistant shows everything is good
Apple Root CA present and trusted in System keychain
Set all trust settings back to System Defaults after testing with “Always Trust”
No expired or duplicate Developer ID intermediates present
codesign Troubleshooting:
Ran:
codesign --force --timestamp --options runtime --sign "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" ./fidelisevents
Consistently received:
Warning: unable to build chain to self-signed root for signer ...
errSecInternalComponent
Confirmed correct identity using:
security find-identity -v -p codesigning
(Shows my Developer ID Application cert as valid)
Keychain order confirmed with security list-keychains
Tried explicit --keychain argument in codesign (no change)
Additional Steps Attempted:
Downloaded and re-installed all relevant Apple intermediates/root certificates from https://www.apple.com/certificateauthority/
Rebooted the Mac and killed/restarted the securityd daemon
Confirmed no use of sudo or root for codesigning
Verified keychain is unlocked
Checked that partition list grants access to codesign (set with security set-key-partition-list -S "apple:codesign:" -s -k "" ~/Library/Keychains/login.keychain-db)
Attempted to codesign a copy of /usr/bin/true (same error)
Ran codesign both with and without --timestamp, both on app bundle and binary
Keychain Access showing:
Certificate and private key present and linked
Correct trust chain
System keychain containing all Apple intermediates/roots
No trust warnings or red Xs
Downloaded the latest Apple CA and Developer ID Root certificates and installed those.
None of the forum searches have helped. AI is likewise confused.
You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.
Hello
I have a qt, CMAKE app, non-xcode one till xcode start supporting cmake.
I have 3 apps, 2 basic ones and 1 very complex ones.
My complex one build/links/notarises/validates/deploys beautifly. I have tear in my eye when I see it build.
The other 2 apps explode and torment me for past 5 days. The build proves is 99% the same, the only thing that a little changes are info.plist and app name+ some minor changes.
Its absolutely bananas and I can't fix it, I'm running out of ideas so if any1 could sugged anything, I'll buy & ship you a beer.
Anyway, errors:
Log: Using otool:
Log: inspecting "/Users/dariusz/Qt/6.9.1/macos/lib/QtCore.framework/Versions/A/QtCore"
Log: Could not parse otool output line: "/Users/dariusz/Qt/6.9.1/macos/lib/QtCore.framework/Versions/A/QtCore (architecture arm64):"
Log: Adding framework:
Log: Framework name "QtCore.framework"
Framework directory "/Users/dariusz/Qt/6.9.1/macos/lib/"
Framework path "/Users/dariusz/Qt/6.9.1/macos/lib/QtCore.framework"
Binary directory "Versions/A"
Binary name "QtCore"
Binary path "/Versions/A/QtCore"
Version "A"
Install name "@rpath/QtCore.framework/Versions/A/QtCore"
Deployed install name "@rpath/QtCore.framework/Versions/A/QtCore"
Source file Path "/Users/dariusz/Qt/6.9.1/macos/lib/QtCore.framework/Versions/A/QtCore"
Framework Destination Directory (relative to bundle) "Contents/Frameworks/QtCore.framework"
Binary Destination Directory (relative to bundle) "Contents/Frameworks/QtCore.framework/Versions/A"
Log: copied: "/Users/dariusz/Qt/6.9.1/macos/lib/QtWebSockets.framework/Versions/A/QtWebSockets"
Log: to "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Versions/A/QtWebSockets"
Log: copy: "/Users/dariusz/Qt/6.9.1/macos/lib/QtWebSockets.framework/Resources" "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Versions/A/Resources"
Log: copied: "/Users/dariusz/Qt/6.9.1/macos/lib/QtWebSockets.framework/Resources/Info.plist"
Log: to "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Versions/A/Resources/Info.plist"
Log: copied: "/Users/dariusz/Qt/6.9.1/macos/lib/QtWebSockets.framework/Resources/PrivacyInfo.xcprivacy"
Log: to "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Versions/A/Resources/PrivacyInfo.xcprivacy"
Log: symlink "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/QtWebSockets"
Log: points to "Versions/Current/QtWebSockets"
Log: symlink "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Resources"
Log: points to "Versions/Current/Resources"
Log: symlink "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/Frameworks/QtWebSockets.framework/Versions/Current"
Log: points to "A"
Log: Using install_name_tool:
Log: in "/AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/MacOS/Agameri_Toolbox"
Log: change reference "@rpath/QtWebSockets.framework/Versions/A/QtWebSockets"
Log: to "@rpath/QtWebSockets.framework/Versions/A/QtWebSockets"
ERROR: "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): /AppBuild/Agameri_Toolbox/Agameri_Toolbox.app/Contents/MacOS/Agameri_Toolbox\n"
ERROR: ""
Even tho I get that error, it will "Notarize" and "greenlight by gatekeeper.
So my automatic build app if he sees error with the __LINKEDIT it will stop deployment.
But even tho he "stops" release of app to public I can still go check binary and when I try to run that I get:
Library not loaded: @rpath/QtConcurrent.framework/Versions/A/QtConcurrent
Referenced from: <69A296DB-8C7D-3BC9-A8AE-947B8D6ED224> /Volumes/VOLUME/*/Agameri_Toolbox.app/Contents/MacOS/Agameri_Toolbox
Reason: tried: '/Users/dariusz/Qt/6.9.1/macos/lib/QtConcurrent.framework/Versions/A/QtConcurrent' (code signature in <192D5FAC-FE8C-31AB-86A7-6C2CE5D3E864> '/Users/dariusz/Qt/6.9.1/macos/lib/QtConcurrent.framework/Versions/A/QtConcurrent' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/Users/dariusz/Qt/6.9.1/macos/lib/QtConcurrent.framework/Versions/A/QtConcurrent' (no such file), '/Volumes/DEV_MAC/02_CODE/Dev/Icarus.nosync/Icarus_Singleton/codeSingleton/libOutput/Release/QtConcurrent.framework/Versions/A/QtConcurrent' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Volumes/DEV_MAC/02_CODE/Dev/Icarus.nosync/Icarus_Singleton/codeSingleton/libOu
(terminated at launch; ignore backtrace)
And here is my build script, its QT based application, I'm using macdeployqt + my own custom signing as the one from macdeployqt breaks on the complex app. (I will post it in next post as apparently there is 7k limit O.O)
I've tried to replace the @rpath/ to @executable_path but that has made a million new issues and I'm just lost.
Hello,
We are currently facing an issue with the Apple Notary Service that is completely blocking our production pipeline.
For the past three days, every single submission has been stuck in the "In Progress" state indefinitely. Some submissions have been pending for over 48 hours, and none of them ever proceed to analysis.
When checking the status via xcrun notarytool history, all entries show "In Progress". Attempting to retrieve logs with xcrun notarytool log always returns: Submission log is not yet available.
This strongly suggests that the processing hasn't even started. This issue occurs consistently from my local machine (MacBook Air M3) and Our GitHub Actions CI workflow.
Both environments are properly configured with Electron + Electron-Builder, and the app is correctly signed and uploaded each time. We have verified multiple times all credentials and code signing settings, no exceptions so far or problems in the pipeline.
Here are a few stuck submission IDs:
This is not a normal delay, it looks like a backend issue affecting our account or this specific App ID. Please escalate this case as soon as possible.
We appreciate your urgent attention.
Best
Topic:
Code Signing
SubTopic:
Notarization
Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper
/Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: replacing existing signature
/Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: resource fork, Finder information, or similar detritus not allowed
failedTask=build stackTrace=Error: Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/
I'm not entirely sure what's causing this issue. Has anyone else encountered this error while signing their macOS app? I’d really appreciate any guidance or solutions you can share.
Topic:
Code Signing
SubTopic:
Notarization
I have multiple submissions for an app notarization. The goal is to distribute the DMG on my website rather than the app store (which I also have a submission in review for). These are the notarization logs:
--------------------------------------------------
createdDate: 2025-06-23T20:26:46.597Z
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
name: Mira-Assist-Fresh.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:53:11.825Z
id: 4bccdfb6-6663-41d3-89bc-c0a15fbdd4b8
name: Mira Assist.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:45:10.342Z
id: fedca538-7619-4a7f-bcc8-3199d6e4b1a6
name: Mira-Assist-1.0.0-Hardened.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:51:04.289Z
id: 19a866b9-e664-4641-b137-6ac852c14ac9
name: Mira Assist-1.0.0.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:44:25.372Z
id: 455209e5-91dd-4324-aac0-d582f88efc95
name: Mira Assist-1.0.0.dmg
status: In Progress
The earliest of which occured more than 18 hours ago.
This is my first time submitting an app for notarization. I also have a developer account that was created ~1-2 days ago.
From what I've read online, notarization usually occurs in less than 10 minutes.
When querying for the logs, it juts says that the submission ID is invalid or the logs aren't available yet.
Submission log is not yet available or submissionId does not exist
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
Hello,
I have created multiple Developer ID Application and Developer ID Installer certificates across different Apple OS versions without keeping the Certificate Signing Requests (CSR).
As I’m not very experienced with Apple’s system, I made this mistake and now I am unable to create new certificates because I have reached the maximum number of certificates allowed.
I develop software based on Electron and have been building and signing my applications with electron-builder, integrating the app signing needed to submit the app to the Apple Store via Transporter.
Here is the relevant portion of my package.json build config:
"mac": {
"appId": "com.nome_app.ext",
"type": "distribution",
"target": [
"mas"
],
"artifactName": "name_app.${ext}",
"category": "public.app-category.utilities",
"provisioningProfile": "build/prov_prof_mac_name_app.provisionprofile"
},
"mas": {
"appId": "com.name_app.ravia",
"hardenedRuntime": false,
"type": "distribution",
"gatekeeperAssess": true,
"artifactName": "name_app.${ext}",
"category": "public.app-category.utilities",
"entitlements": "build/entitlements.mas.plist",
"extendInfo": {
"NSMicrophoneUsageDescription": "This app requires microphone access.",
"NSCameraUsageDescription": "This app requires webcam access."
},
"entitlementsInherit": "build/entitlements.mas.inherit.plist"
}
}
Currently, I have recreated the Mac Developer Application and Mac Developer Installer certificates, but without valid Developer ID Installer and Developer ID Application certificates, I always get this error during build:
`skipped macOS application code signing reason=cannot find valid "Developer ID Application" identity or custom non-Apple code signing certificate, it could cause some undefined behaviour, e.g. macOS localized description not visible, see https://electron.build/code-signing
allIdentities=
718241A413826C6A97E2062EAEC155BEF5330CCA "iPhone Distribution: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)" (CSSMERR_TP_NOT_TRUSTED)
60B360CCE27FE915799FAE7C8E6A16962F2DE9B0 "3rd Party Mac Developer Installer: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)" (CSSMERR_TP_NOT_TRUSTED)
4518A8CE3BAC4F27B09D654DA14F52FBE15A0A85 "3rd Party Mac Developer Application: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)" (CSSMERR_TP_NOT_TRUSTED)
... (additional identities with CSSMERR_TP_NOT_TRUSTED)
Valid identities only:
718241A413826C6A97E2062EAEC155BEF5330CCA "iPhone Distribution: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)" (CSSMERR_TP_NOT_TRUSTED)
...
• signing file=dist/mas/Studio Medico Specialistico.app platform=mas type=distribution identityName=3rd Party Mac Developer Application: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ) identityHash=4518A8CE3BAC4F27B09D654DA14F52FBE15A0A85 provisioningProfile=build/prov_prof_mac_studiomedicospecialistico.provisionprofile
• Command failed multiple times:
codesign --sign "3rd Party Mac Developer Application: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)" --force --timestamp --entitlements build/entitlements.mas.inherit.plist /path/to/app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/af.lproj/locale.pak
Warning: unable to build chain to self-signed root for signer "3rd Party Mac Developer Application: RAVIA SOFTWARE DI VILLANOVA DOMENICO ANTONIO (T9UD6J5HXZ)"
Error: errSecInternalComponent
From my understanding, the system cannot find a valid Developer ID Application identity for signing. The existing certificates all show the CSSMERR_TP_NOT_TRUSTED error and the signing command fails with errSecInternalComponent.
**I have confirmed that the certificates are installed in my keychain, but they may be missing private keys or not fully trusted.
Is there a possibility to reset my Apple Developer account’s Developer ID Application and Developer ID Installer certificates, so I can start fresh and generate new valid certificates?
Could you please advise on how to proceed or if there is any way to clear the current certificate limit?**
Thank you very much for your help.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
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.
I've been successfully notarizing my apps for a year or so now, with intermittent releases every so often, usually succeeding with notarization in a couple of minutes.
These apps are all written in Python, but I worked through all the jank required to get them to notarize cleanly a while ago and have no issues since.
Today I submitted a couple of builds which have been stuck for hours. They're just "in progress", so no logs I can look at, no emails or anything on my developer account page.
How can I begin to debug this?
Successfully received submission info
createdDate: 2025-06-24T18:43:37.140Z
id: 8d1a1ca9-f0ad-426f-a714-89aaf9e01a07
name: pinpal-2025.6.25.for-notarizing.app.zip
status: In Progress
I should note that in addition to the comment added within 10 minutes of creation of this issue, within the last day, we also have:
https://developer.apple.com/forums/thread/789389
https://developer.apple.com/forums/thread/789599
https://developer.apple.com/forums/thread/789995
So it seems pretty likely something is going on on the backend.
Hello,
I went through the verification process to get the Tap to Pay on iPhone entitlement, and after a couple of corrections I was finally assured that I was granted the entitlement for production use.
However, in App Store Connect, I can only see "Development" for "Provisioning Support" of the entitlement, and I'm not able to publish the app to Testflight because the profile doesn't support the entitlement (I'm using automatic code signing with XCode).
Where is this going wrong? The Tap to Pay support assured me they granted the right entitlement and pointed me to the developer support.
Thank you,
Johannes
The driver does not show up in the app settings after switching to “DriverKit USB Transport - VendorID”.
Previously, the app used “DriverKit USB Transport (development)” and everything worked as expected.
The entitlements looked like this:
<?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>
<key>com.apple.developer.driverkit</key>
<true/>
<key>com.apple.developer.driverkit.transport.usb</key>
<array>
<dict>
<key>idVendor</key>
<string>*</string>
</dict>
</array>
</dict>
</plist>
I received approval to use “DriverKit USB Transport - VendorID”.
I updated the App ID configuration in the portal, removed all development entitlements, updated the provisioning profile, and edited the driver’s .entitlements as follows:
<?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>
<key>com.apple.developer.driverkit</key>
<true/>
<key>com.apple.developer.driverkit.transport.usb</key>
<array>
<dict>
<key>idVendor</key>
<integer>1111</integer>
</dict>
</array>
</dict>
</plist>
The app installs on an iPad with an M processor, but the driver does not appear in the settings.
In the logs I see the following:
272 debug 19:50:42.005193+0300 installd 7935 signing bytes in 5 blob(s) from /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.bugkAE/extracted/Payload/****.app/SystemExtensions/****Driver.dext/****.Driver(arm64)
272 debug 19:50:42.012068+0300 installd open(/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.bugkAE/extracted/Payload/****.app/SystemExtensions/net.svedm.****.SDRDriver.dext/Info.plist,0x0,0x1b6) = 4
272 debug 19:50:42.012712+0300 installd 0xc2e14c618 done serializing <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>application-identifier</key><string>****.Driver</string><key>com.apple.application-identifier</key><string>****</string><key>com.apple.developer.driverkit</key><true/><key>com.apple.developer.driverkit.transport.usb</key><array><dict><key>idVendor</key><integer>3034</integer></dict></array><key>com.apple.developer.team-identifier</key><string>****</string><key>com.apple.security.get-task-allow</key><true/><key>get-task-allow</key><true/></dict></plist>
0 error 19:53:08.930054+0300 kernel Sandbox: MyApp(844) deny(1) sysctl-read kern.bootargs
0 error 19:53:08.931571+0300 kernel Sandbox: driverkitd(77) deny(1) syscall-unix 284
syscall-unix-denied-SIGKILL
0 error 19:53:09.985946+0300 kernel 1 duplicate report for Sandbox: driverkitd(77) deny(1) syscall-unix 284
syscall-unix-denied-SIGKILL
0 error 19:53:09.985985+0300 kernel Sandbox: MyApp(844) deny(2) file-test-existence /usr/bin/swift-backtrace
0 error 19:53:09.986011+0300 kernel Sandbox: MyApp(844) deny(2) file-test-existence /usr/bin/arm64e
But I don’t quite understand what is going wrong. Any ideas?
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
1.Provisioning profile "xxx" doesn't include signing certificate "Developer ID Application: xxxxx".
2.Provisioning profile "xxx" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement.
I decoded the profile,
<dict>
<key>com.apple.developer.system-extension.install</key>
<true/>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>packet-tunnel-provider-systemextension</string>
<string>app-proxy-provider-systemextension</string>
<string>content-filter-provider-systemextension</string>
<string>dns-proxy-systemextension</string>
<string>dns-settings</string>
<string>relay</string>
<string>url-filter-provider</string>
<string>hotspot-provider</string>
</array>
<key>com.apple.security.application-groups</key>
<array>
<string>xxxxx</string>
<string>xxxxx</string>
</array>
<key>com.apple.developer.networking.vpn.api</key>
<array>
<string>allow-vpn</string>
</array>
<key>com.apple.application-identifier</key>
<string>xxxxx</string>
<key>keychain-access-groups</key>
<array>
<string>xxxxx</string>
</array>
<key>com.apple.developer.team-identifier</key>
<string>xxxxx</string>
</dict>
Kindly help me to resolve this.
Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team?
I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements.
I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message:
Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement.
I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know.
Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows:
Export the .app from the Xcode archive.
Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension.
Sign the app and its components in the following order:
codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/
codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw>
codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/
codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app
Verify the code signature:
codesign --verify --deep --strict --verbose=4 <app>.app
- <app>.app: valid on disk
- <app>.app: satisfies its Designated Requirement
Create a ZIP archive using:
ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip
Notarize the app with notarytool and staple it.
The notarization completes successfully with errors: nil.
Package the notarized app into a DMG, notarize, and staple the DMG.
The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; }
As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier.
When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked.
My question is:
Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Network Extension
Gatekeeper
Code Signing
Developer ID
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
我没有勾选entitlements 中的” com.apple.security.network.server“和” com.apple.security.device.usb“,但是确实在打包时又自动出现在包里,我现在无法解决这个问题,我需要帮助,谢谢
我的.entitlements 文件如下:
排查命令:
codesign -d --entitlements :- ./Device\ Guard.app
Executable=/Users/zhanghai/Library/Developer/Xcode/DerivedData/MacGuardApp-fvfnspyxcojxojdfclyohrnupgsh/Build/Products/Debug/Device Guard.app/Contents/MacOS/Device Guard
warning: Specifying ':' in the path is deprecated and will not work in a future release
This is a continuation of my own old post that became inactive to regain traction. I am trying to resolve issues that arise when distributing a macOS app with a SysExt Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate.
To directly distribute the app, I start with exporting the .app via Archive in Xcode.
After that, I create a new Developer ID provisioning profile for both the app and sysext and replace the embedded ones in the .app package.
After I have replaced the provisioning profiles and the have the entitlements files ready, I start signing the frameworks, sysext and parent app.
codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/Frameworks/<fw>.framework/Versions/A/<fw>
codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/
codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/MacOS/<sysext>
codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app
After validation is successful with
codesign --verify --deep --strict --verbose=4 <app>.app
I zip the package, notarize and staple it
ditto -c -k --keepParent "<app>.app" "<app>..zip"
xcrun notarytool submit <app>.zip --keychain-profile “”<credents> --wait
xcrun stapler staple <app>.app
After that I finish creating signed and notarized .dmg/.pkg.
hdiutil create -volname “<app>” -srcfolder “<app>.app/" -ov -format UDZO ./<app>.dmg
codesign --force --sign "Developer ID Application: <name>" <app>.dmg
xcrun notarytool submit <app>.dmg --keychain-profile "<credentials>" --wait
xcrun stapler staple <app>.dmg
Then when I move the .dmg to a clean system, open the .dmg, move the .app to the Applications folder, the attempt to run it fails with “The application “” can’t be opened.”. When I look into the console, the gatekeeper disallows the launch job with the message:
86127 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: {
"com.apple.developer.networking.networkextension" = (
"packet-tunnel-provider-systemextension"
);
"com.apple.developer.system-extension.install" = 1;
"com.apple.developer.team-identifier" = <teamid>;
"keychain-access-groups" = (
“<teamid>.<app>.AppGroup"
);
} com.apple.ManagedClient
<app>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, keychain-access-groups, com.apple.developer.system-extension.install, com.apple.developer.team-identifier
LAUNCH: Runningboard launch of <app> <private> returned RBSRequestErrorFailed, error Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600001a25830 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}, so returning -10810
I went through all possible formats (macOS-Style and iOS-Style App Group IDs) and combinations of appgroups according to the post “App Groups: macOS vs iOS: Working Towards Harmony”. But none of those work for me. The weird part is that when I try the same steps on different developer account, I am able to get the app running. What can be wrong?
Topic:
Code Signing
SubTopic:
Entitlements
Tags:
Network Extension
Gatekeeper
Code Signing
Developer ID
Hi all,
I’ve run into a signing/entitlements problem that shows up only on Big Sur (11.x).
The very same .app launches perfectly on Monterey (12), Ventura (13), Sonoma (14 / 14.5) and Sequoia (15).
Failure on macOS 11
com.apple.xpc.launchd[1] (application.app.myapp.exams.566312.566318[1602]):
removing service since it exited with consistent failure –
OS_REASON_CODESIGNING |
When validating …/MyAppNameBlurred 3.13.1.app/Contents/MacOS/MyAppNameBlurred 3.13.1:
Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements:
Binary is improperly signed.
Launching from Terminal:
open -a "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app"
kLSNoLaunchPermissionErr (-10826) | Launchd job spawn failed with error: 153
What I’ve already checked
# signature itself
codesign -dvvv "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app"
# => valid, Authority = Developer ID Application, runtime enabled
# full deep/strict verification
codesign --verify --deep --strict -vvv "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app"
# => “satisfies its Designated Requirement”
# Gatekeeper assessment
spctl --assess --type execute --verbose=4 "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app"
# => accepted (override security disabled)
# embedded provisioning profile matches bundle ID
codesign -d --entitlements :- "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" | plutil -p -
security cms -D -i "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app/Contents/embedded.provisionprofile" \
| plutil -extract Entitlements xml1 -o -
# => both show the AAC entitlement and everything looks in order
# notarization ticket
stapler validate "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app"
# => “The validate action worked!”
Deployment target: MACOSX_DEPLOYMENT_TARGET = 11.0
Entitlement added: com.apple.developer.automatic-assessment-configuration = true
Provisioning profile: generated this year via Developer ID, includes the assessment entitlement and nothing else unusual.
Runtime code: we call AEAssessmentSession's network configuration part only on 12 + (guarded with @available(macOS 12.0, *)).
Has anyone hit this mismatch on 11.x? Could Big Sur be expecting something older or idk?
Any pointers appreciated!
Thanks!
I have a valid Developer ID Certificate, I've used it to sign an app locally and send the app to other machines of my colleagues to make sure it works and does not get triggered by GateKeeper
Now I want to automate the process of signing and notarization on github actions and so I want to export my certificate and upload it there.
Initially I tried uploading both the Developer ID Certificate and the G2 CA both as .cer files encoded in base64. But apparently I need my certificate to be in .p12 format
When I try to export it from keychain access the option to export as .p12 is disabled. So how can I do it ?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Signing Certificates
Code Signing
Developer ID