Hello Team,
I am building an Electron app and building platform-related installers line exe, appimage and dmg. To build an installer, I am using the electron builder library.
When I do code signing and notarization, the signing process gets stuck without any error. I have verified certificate and other information are correct. Below are more details.
Versions
@electron/notarize": "^2.5.0
@electron/rebuild": "3.3.0
electron": "26.2.1
electron-builder": "^25.1.8
electron-devtools-installer": "3.2.0
Current Setup
CircleCI pipeline
Developer ID Application certificate is properly installed and verified
Notarization is configured in both package.json and build arguments
I see the last log as below where it gets stuck without any error.
• selecting signing options file=release/build/mac-arm64/xxxx Assistant.app entitlements=assets/entitlements.mac.plist hardenedRuntime=true timestamp=http://timestamp.apple.com/ts01 requirements=undefined additionalArguments=[]
Package.json
"build": {
"productName": "xxxxx - Your AI Work xxxxx",
"executableName": "xxxx xxxxx",
"artifactName": "xxxxx-Assistant-${version}-${arch}.${ext}",
"appId": "org.erb.xxxx",
"asar": true,
"asarUnpack": "**\\*.{node,dll}",
"files": [
"dist",
"node_modules",
"package.json",
"assets/tray.ico",
"!**/*.lproj/**/*",
"!**/locale.pak",
"!locales/**/*"
],
"afterSign": ".erb/scripts/notarize.js",
"mac": {
"timestamp": "http://timestamp.apple.com/ts01",
"identity": "xxxxx Technology Inc (xxxxxxxx)",
"target": [
"dmg",
"zip"
],
"electronLanguages": [
"en-US"
],
"icon": "build/mac-icon/Logo512x512.icns",
"type": "distribution",
"hardenedRuntime": true,
"entitlements": "assets/entitlements.mac.plist",
"entitlementsInherit": "assets/entitlements.mac.plist",
"gatekeeperAssess": false
},
"dmg": {
"icon": "build/mac-icon/xxxxxxLogo512x512.icns",
"contents": [
{
"x": 130,
"y": 220
},
{
"x": 410,
"y": 220,
"type": "link",
"path": "/Applications"
}
]
},
"directories": {
"app": "release/app",
"buildResources": "assets",
"output": "release/build"
},
"extraResources": [
"./assets/**"
]
}
Entitlement
<?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>
<!-- Required for Electron/Chromium JIT -->
<key>com.apple.security.cs.allow-jit</key>
<true/>
<!-- Required for basic Electron functionality -->
<key>com.apple.security.inherit</key>
<true/>
<!-- Required for network communication (REST APIs) -->
<key>com.apple.security.network.client</key>
<true/>
</dict>
</plist>
I have made the following verification.
I already tried on multiple macos with different processors.
Verified on a high-speed network.
Certificate is exported to .p12 and verified.
All Env Variables are set with the correct value. (APPLE_APP_SPECIFIC_PASSWORD+APPLE_ID+APPLE_TEAM_ID )
I have tried with CSC_LINK/CSC_KEY_PASSWORD + Keystore as well.
Appriciate any help.
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
When building to macOS on GameMaker, I get the error "this identity cannot be used for signing code" when using the Developer ID Installer certificate. The certificate was neither expired nor revoked, but nonetheless I created new certificates to start fresh but am still getting that error. I don't get issues building to iOS via GameMaker, just to macOS.
If it makes any difference, I only noticed this issue started happening after I converted my Apple Developer Program account from an individual account to an organizational account, although it was weeks to months before I built to macOS via GameMaker before then, so I don't know if it correlates with that.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
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
I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts.
Is it possible to write a script that automates the entire process of codesigning the app?
To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution?
Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning?
If possible, I’d appreciate a step-by-step explanation and a sample command-line script to:
Codesign the app properly
Package it into a signed .dmg
Remove the quarantine attribute for local testing or distribution
Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?
Topic:
Code Signing
SubTopic:
General
Hi there,
We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see:
could not insert bundle at <private> into manager: <private>
As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad.
This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build.
We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight.
What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities.
The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details.
If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent.
Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+).
We've been battling this issue for months on and off, so would appreciate some help.
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
Howdy,
I thought this would be an easy question, but it turns out it's really not! In fact, it flies in the face of how the Apple ecosystem is set up. That said, I still need an answer to be able to inform our customers of what their app update options are.
The question: Does app store provisioning ever expire? Based on the very limited information I can find, it either expires in one year, two years, or never. Anecdotal evidence seems to indicate that the answer could be never, but I need to confirm this.
The use case: Some of our customers are very old school. They tend to find a technical solution and stick with it. As such, they do not update apps regularly on their field iPads. They generally only update when they are forced to. They use MDM to deploy the app, and would set the MDM not to pull updated apps from the app store when available, essentially keeping the same version of the app in use for as much as 3 years or more. If this were to happen, I need to know if the provisioning for the old version of the app will ever expire if they get it from the app store.
I know with an enterprise deployment of .ipa files via MDM, the app provisioning/certificate will expire after 1 or 2 years (can't remember which atm), but I can't find an answer about app store provisioning. Hopefully someone can provide me with an answer on this forum.
Thanks in advance,
Mapguy
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
App Store
Provisioning Profiles
Device Management
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
The device UDID was registered to the developer account 40 hours ago, the STATUS column was "processing" in the first 24 hours, then turned to empty.
But I still can't run my app (with distribution method "development"), when I try to run it after download it through my OTA URL, it prompts “the app cannot be installed because its integrity could not be verified” but everything runs good on a iPhone which was registered a month ago.
What should I do now? keep waiting?
I've got a Flutter app that is a “reader” app. The External Link Account Entitlement has already been requested and granted. It is already added as an Additional Capability to the App ID. The com.apple.developer.storekit.external-link.account entitlement is already present in the .entitlements file. Also SKExternalLinkAccount key is added to the Info.plist file with the correct URL.
ExternalLinkAccount.open() is invoked via a MethodChannel call handler and things work perfectly in debug mode. The modal appears as expected and opens the link in the external browser.
Xcode archive is also sucessful and the entitlement seems to be in place when inspecting the app with:
codesign -d --entitlements :- ./path/to/app
But when trying to distribute the app via Xcode the entitlement disappears. Other entitlements are not affected by this issue, eg.: com.apple.developer.associated-domains for universal links. This happens with automatically managed singing and a manually selected provisioning profile as well. When inspecting the latter in Xcode the necessary capability and entitlement is included. But when distributing to App Store Connect the entitlement disappears with both recommended and custom settings.
I ran flutter clean mulitple times. What am I missing here?
I am receiving an entitlement error from stripe terminal SDK when integrating Tap to Pay from apple in the info.plist.
Im hoping that someone can give me their input on my error output rather than diving into the stripe sdk to point me in the right direction of something I may have missed with entitlements.
I have been approved for tap to pay entitlement and am following the instructions here from apple: https://developer.apple.com/documentation/proximityreader/setting-up-the-entitlement-for-tap-to-pay-on-iphone
com.apple.developer.proximity-reader.tap-to-pay
Yes, this is very likely the completely wrong way to do things but I would like to ask regardless.
Currently with windows/linux I can perform an in-situ upgrade of an application by performing a download of the binary 'foo' and then doing a rename-and-replace and subsequently requesting the licencee to restart the program and all is good.
With macOS, as the binary is within the foo.app ( Contents/macOS/foo ) I imagine I cannot perform a similar operation without breaking the signing of the foo.app itself?
....or, can I individually sign the binary foo for macOS and perform the same type of operation?
Download new foo as foo.new
rename current foo.app/Content/macOS/foo -> foo.old
rename foo.new -> foo
Restart application
Again, I know this is very likely an un-macOS way of performing the task but as you can imagine with supporting cross-platform development it's usually easier to maintain a consistent method even if it's "not ideal".
Topic:
Code Signing
SubTopic:
General
Hi guys,
I got an error about mac notarization result return 132.
here is the stack trace on the logs:
2025-02-25 02:53:55,503 ERROR [org.ecl.cbi.ws.mac.not.xcr.not.NotarytoolNotarizer] (macos-notarization-service-pool-thread-13) Error while parsing the output after the upload of '/tmp/macos-notarization-service/pending-files/myapplication.dmg' to the Apple notarization service: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Premature end of file.
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1465)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1013)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:326)
at java.xml/javax.xml.parsers.SAXParser.parse(SAXParser.java:197)
at org.eclipse.cbi.ws.macos.notarization.xcrun.common.PListDict.fromXML(PListDict.java:134)
at org.eclipse.cbi.ws.macos.notarization.xcrun.notarytool.NotarytoolNotarizer.analyzeSubmissionResult(NotarytoolNotarizer.java:39)
at org.eclipse.cbi.ws.macos.notarization.xcrun.common.NotarizationTool.upload(NotarizationTool.java:50)
at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.lambda$uploadFailsafe$3(Notarizer.java:65)
at net.jodah.failsafe.Functions.lambda$get$0(Functions.java:48)
at net.jodah.failsafe.RetryPolicyExecutor.lambda$supply$0(RetryPolicyExecutor.java:66)
at net.jodah.failsafe.Execution.executeSync(Execution.java:128)
at net.jodah.failsafe.FailsafeExecutor.call(FailsafeExecutor.java:379)
at net.jodah.failsafe.FailsafeExecutor.get(FailsafeExecutor.java:68)
at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.uploadFailsafe(Notarizer.java:65)
at org.eclipse.cbi.ws.macos.notarization.NotarizationService.lambda$notarize$0(NotarizationService.java:192)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Do you know why?
If you have any thread or documents telling about the details of return values of the command: 'xcrun notarytool submit'
Thanks in advance for any hint to solve the following account problem:
I tried to store credentials for notarizing.
Presumably with the wrong combination of entries (similar to signing) – using the name of my university instead of my Apple Account.
xcrun notarytool store-credentials "notarytool-password" --apple-id "Berliner Hochschule fuer Technik" --team-id "8YAW3HL2QP" --password "my Apple-Account-pw"
.. retried assuming a syntax error (like missing ").
Got the error message:
This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name.
Validating your credentials...
`Error: HTTP status code: 401. Your Apple ID has been locked. Visit iForgot to reset your account (https://iforgot.apple.com), then generate a new app-specific password. Ensure that all authentication arguments are correct.`
Happy to see: Signing is not affected and I still an can log in to my account on developer.apple.com. So notarizing “only” seems to be affected.
But how to reset the account to resolve the issue?
The iforgot.apple.com link does not help - I provided my iPhone-number but did not receive further messages – neither on the iPhone nor on my “developer” macbook.
Many thanks in advance
All the best
Florian
Hi there!
I have an issue with uploading a PKG installer to the MacOS AppStore.
Uploading with:
xcrun altool --upload-app -t macos -f $PKGPATH -u $DEVELOPER_ID -p $APP_SPECIFIC_PWD
results in error:
*** Error: Validation failed Invalid Provisioning Profile. The provisioning profile included in the bundle com.frogblue.frogCom [com.frogblue.frogCom.pkg/Payload/frogSIP.app] is invalid. [Missing code-signing certificate.] For more information, visit the macOS Developer Portal. (ID: fc4e5488-6d09-4ab2-b1f7-017a33c69723) (409)
Application seems to be correctly code signed with „3rd Party Mac Developer Application“ certificate.
codesign -dv --verbose=4 /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app
Identifier=com.frogblue.frogCom
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=266432 flags=0x10000(runtime) hashes=8315+7 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=918784
Hash type=sha256 size=32
CandidateCDHash sha256=923de799a54616706b76050b50b7ee6d59f8355a
CandidateCDHashFull sha256=923de799a54616706b76050b50b7ee6d59f8355a65aa7cce03e34bb2033da1e9
Hash choices=sha256
CMSDigest=923de799a54616706b76050b50b7ee6d59f8355a65aa7cce03e34bb2033da1e9
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=31604736
Executable Segment flags=0x1
Page size=4096
CDHash=923de799a54616706b76050b50b7ee6d59f8355a
Signature size=9109
Authority=3rd Party Mac Developer Application: frogblue TECHNOLOGY GmbH (UG2P6T5LNH)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Timestamp=26.02.2025 at 10:07:08
Info.plist entries=31
TeamIdentifier=UG2P6T5LNH
Runtime Version=14.5.0
Sealed Resources version=2 rules=13 files=1124
Internal requirements count=1 size=212
The PKG build with productbuild seems also be correctly code signed with„3rd Party Mac Developer Installer“ certificate.
pkgutil --check-signature /Users/dietmar.finkler/Desktop/frogSIP/frogSIP-1.2a2.pkg
Status: signed by a developer certificate issued by Apple (Development)
Certificate Chain:
1. 3rd Party Mac Developer Installer: frogblue TECHNOLOGY GmbH (UG2P6T5LNH)
Expires: 2026-02-25 17:17:54 +0000
SHA256 Fingerprint:
D1 9E AC 27 C7 26 F3 2E 1E F5 50 2C 7A 1B 1D FB 54 D6 17 C1 1C 58
C1 7E F8 87 B6 44 D1 49 17 DC
------------------------------------------------------------------------
2. Apple Worldwide Developer Relations Certification Authority
Expires: 2030-02-20 00:00:00 +0000
SHA256 Fingerprint:
DC F2 18 78 C7 7F 41 98 E4 B4 61 4F 03 D6 96 D8 9C 66 C6 60 08 D4
24 4E 1B 99 16 1A AC 91 60 1F
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
SHA256 Fingerprint:
B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C
68 C5 BE 91 B5 A1 10 01 F0 24
KeyChain login items show both "3rd Party Mac Developer Application" and "3rd Party Mac Developer Installer“ certificates.
But checking with
security find-identity -v -p codesigning
shows only the "3rd Party Mac Developer Application“ certificate. "3rd Party Mac Developer Installer“ is missing.
I check also the entitlement in the app package, which looks ok for me.
codesign -d --entitlements :- /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app
<?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>com.apple.application-identifier</key><string>UG2P6T5LNH.com.frogblue.frogCom</string><key>com.apple.developer.aps-environment</key><string>production</string><key>com.apple.developer.associated-domains</key><array><string>applinks:go.dev.frogblue.cloud</string><string>applinks:go.test.frogblue.cloud</string><string>applinks:go.prod.frogblue.cloud</string></array><key>com.apple.developer.team-identifier</key><string>UG2P6T5LNH</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.cs.disable-library-validation</key><true/><key>com.apple.security.device.audio-input</key><true/><key>com.apple.security.device.camera</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/></dict></plist>
What I am missing?
Thanx for any hint!
Regards
Dietmar Finkler
Displaying attribute for a private key I see a number of applications that are allowed to access it without needing a password e.g. racoon; Keychain Access.app; Certificate Assitant.app etc..
I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that :(
How do I do it please
Topic:
Code Signing
SubTopic:
General
We have a Mac app that uses some restricted macOS entitlements, thus to test it we embed a development provisioning profile, that needs to contain the correct provisioning UDID.
Typically, for test VMs, we extract the provisioning and UDID and add it to the developer portal and then re-generate the provisioning profiles.
However when we try to do this in our newly created VM (Apple Silicon), our executable won't run, and macOS logs that the provisioning profile doesn't allow the device:
2025-06-12 12:37:52.168 E taskgated-helper[27489:e97da] [com.apple.ManagedClient:ProvisioningProfiles] embedded provisioning profile not valid: file:///Applications/foo.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." UserInfo={NSLocalizedDescription=Provisioning profile does not allow this device.}
2025-06-12 12:37:52.169 E taskgated-helper[27489:e97da] [com.apple.ManagedClient:ProvisioningProfiles] Disallowing com.company.foo because no eligible provisioning profiles found
2025-06-12 12:37:52.169 Df amfid[112:e99b0] [com.apple.xpc:connection] [0xb34c74a00] invalidated because the current process cancelled the connection by calling xpc_connection_cancel()
2025-06-12 12:37:52.169 Df taskgated-helper[27489:e97da] [com.apple.xpc:connection] [0x839144000] invalidated because the client process (pid 112) either cancelled the connection or exited
2025-06-12 12:37:52.169 E amfid[112:e91ac] [com.apple.MobileFileIntegrity.framework:default] Failure validating against provisioning profiles: <private>
2025-06-12 12:37:52.169 E amfid[112:e91ac] [com.apple.MobileFileIntegrity.framework:default] Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=<private>, NSLocalizedDescription=No matching profile found}
2025-06-12 12:37:52.169 Df amfid[112:e91ac] /Applications/foo.app/Contents/MacOS/foo not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/foo.app/, NSLocalizedDescription=No matching profile found}
The UDID for this VM does look weird, in System Profiler:
But I can verify that this UDID string is present in the provisioning profile embedded in the app bundle:
$ security cms -D -i /Applications/foo.app/Contents/embedded.provisionprofile | grep -i 7cd9234e9aa4fa8ba528ee417f857b2c993a20a3
<string>7CD9234E9AA4FA8BA528EE417F857B2C993A20A3</string>
I also tried deleting the manually added device from the Developer portal and installing Xcode on the VM and letting Xcode register the device, but I end up in the same situation there. Even after letting Xcode itself register the device, it says that "this device not registered to your account" and then when I click "Register device" it changes into " already exists".
Has anyone else managed to get Mac development provisioning profiles to work in a VM?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Entitlements
macOS
Code Signing
Virtualization
Hello everyone,
I'm facing a critical, blocking issue where my developer account (Team ID: K655PX7A46) is unable to generate a valid provisioning profile with the App Attest entitlement. I have confirmed this is a server-side issue and am hoping to get visibility from an Apple engineer who can investigate.
The Problem:
When I generate a provisioning profile for an App ID with the "App Attest" capability enabled, the resulting profile is defective. It is missing the required com.apple.developer.app-attest.environment key in its entitlements dictionary, causing Xcode to fail the build.
What I Have Proven:
The issue is not a misconfiguration. The App Attest capability is correctly enabled and saved on the App ID configuration page.
The issue is not isolated to one App ID. I created a brand new App ID from scratch, enabled the capability during creation, and the server still generates a defective profile with the same missing entitlement.
I have definitive proof by inspecting the downloaded .mobileprovision file. The contents confirm the required key is missing.
Steps to Reproduce on My Account:
Create a new App ID on the Developer Portal.
Enable the "App Attest" capability and save.
Generate a new "iOS App Development" provisioning profile for this App ID.
Download the profile and inspect its contents via security cms -D -i [profile].
Observe that the com.apple.developer.app-attest.environment key is missing.
The Evidence (Contents of the Defective Profile):
Here is the output from inspecting the profile for a brand new App ID (com.technology519.linksi.app2). As you can see, the correct entitlement is missing, and an incorrect devicecheck entitlement is present instead.
This is a critical bug in the provisioning profile generation service for my account that is blocking all development. I have already filed a support ticket (Case #102721408444) but have so far only received generic, unhelpful responses.
Can an Apple engineer please investigate this server-side issue with my account?
Thank you.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Entitlements
Signing Certificates
App Attest
Code Signing
In the LightweightCodeRequirements framework, there is a LaunchCodeRequirement object which can be used as a requirement object for a Process for example.
What I don't understand (I admit my macOS low-level knowledge is limited) is that how can this be used in a secure way that doesn't fall victim of a Time-of-Check/Time-of-Use issue.
e.g.
I specify a LaunchCodeRequirement via Process.launchRequirement for my process, let's say /usr/local/bin/mycommandlinetool.
The LaunchCodeRequirement specifies my development team and a developer ID certificate.
The process must be started in some form, before a SecCode/SecTask object can be created, rather than a SecStaticCode object (which only guarantees its validity checks to be intact as long as the file is not modified).
But if the process was started, then I have no tools in my set to prevent it from executing its initialization code or similar. Then, by the time I'm able to check via SecCode/SecTask functions the LaunchCodeRequirement, I might have already ran malicious code - if mycommandlinetool was maliciously replaced.
Or does the operating system use a daemon to copy the executable specified for Process to a secure location, then creates the SecStaticCode object, assesses the LaunchCodeRequirement and if passed, launches the executable from that trusted location (which would make sure it is immutable for replacement by malicious actors)?
I have a hard time understanding how this works under the hood - if I remember correctly these are private APIs.
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