One code signing issue I commonly see, both here on DevForums and in my Day Job™ with DTS, is that the codesign command fails with errSecInternalComponent. This issue crops up in a wide variety of circumstances and the correct fix depends on the specific problem. This post is my attempt to clarify the potential causes of this error and help folks resolve it. If you have any questions or comments about this, please start a new thread, tagging it with Code Signing so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving errSecInternalComponent errors during code signing In some circumstances the codesign command might fail with the error errSecInternalComponent. For example: % codesign -s "Apple Development" "MyTrue" MyTrue: errSecInternalComponent This typically affects folks who are signing code in a nonstandard environment, for example, when logged into a Mac via SSH or when signing code on a continuous integration (CI) server. This post explains how to resolve such issues, starting in the simplest case, signing from Terminal app, and then going on to discuss SSH and other contexts. IMPORTANT Before going further, make sure you understand the difference between a digital identity and a certificate. See TN3161 Inside Code Signing: Certificates for the details. Test from Terminal Code signing makes extensive use of the keychain, and that’s sensitive to the execution context in which it’s running. So, the first step in resolving this problem is to test your code signing from Terminal. To start, log in to the Mac using the GUI. Note If you don’t have access to the GUI, see Working without the GUI, below. Check that Keychain Access shows that your code signing identity’s certificate is trusted. Select the certificate and look for a green checkmark with the text “This certificate is valid”. If you see a red cross with an explanatory text like “… certificate is not trusted”, follow the instructions in Fixing an untrusted code signing certificate. Note macOS 15 moved Keychain Access out of the Utilities folder. The easiest way to find and launch Keychain Access is to use Spotlight. In Terminal, run the security tool to check that your code signing identity is available: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 valid identities found If the identity is missing from the Matching identities list, you don’t have a code signing identity to sign with. If you see your code signing identity’s certificate in the keychain, it’s possible that you’re missing its private key. See Certificate Signing Requests Explained for more about that issue. If the identity is shown in the Matching identities list but not in the Valid identities only list, see Fixing an untrusted code signing certificate. This example assumes that you’re testing with an Apple Development signing identity. If you’re using something else, you’ll see a different identity name in this list. Use that identity name in the codesign command below. Still in Terminal, make a copy of the true tool to use for this test: % cp "/usr/bin/true" "MyTrue" Try to sign it: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature The -f flag tells codesign to replace the existing signature. This command may display one or more keychain dialogs but, once you respond to those, it should correctly sign MyTrue. If it doesn’t, skip down to the Terminal failure section at the end of this post. Eliminate keychain alerts When you signed your code in the previous section, you may have seen one of two different types of keychain alerts: Keychain unlock dialog Access control list (ACL) dialog The keychain unlock dialog looks like this: codesign wants to use the … keychain. Please enter the keychain password. Password: [ ] [Cancel] [[OK]] The keychain containing your code signing identity is locked, and you must enter the keychain password to unlock it. You rarely see this dialog when logged in via the GUI because the system automatically unlocks the login keychain when you log in. However, the underlying cause of this alert will become relevant in the next section, when you log in via SSH. The ACL dialog looks like this: codesign wants to sign using key … in your keychain. To allow this, enter the … keychain password. Password: [ ] [Always Allow] [Deny] [[Allow]] The ACL for the your code signing identity’s private key prevents codesign from using the private key without your explicit approval. If you enter your password and click Allow, codesign can use the private key once. If you click Always Allow, the system adds codesign to the private key’s ACL so that it doesn’t have to ask again. To avoid this alert in the future, enter your keychain password and click Always Allow. Now repeat the codesign command from the previous section. It will sign the code without presenting any dialogs. Test over SSH Once you can sign your code in Terminal without seeing any dialogs, it’s time to repeat that process over SSH. To start, log out of the GUI and then log in via SSH. If you’re testing on a CI system, log in to that system by running ssh from Terminal on your Mac. If you want to test on your local Mac, choose one of these options If you have a second Mac, log in to that second Mac using the GUI, launch Terminal, and then run ssh to log in to your main Mac from there. If you have an iPad, use a third-party iPad SSH app to log in to your main Mac over SSH. Use a virtualisation app to run a macOS guest that you can treat like your CI system. Once you’re logged in over SSH, repeat the signing command from the earlier section: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature MyTrue: errSecInternalComponent This fails because: The system locked the keychain when you logged out of the GUI. Logging in via SSH does not unlock the keychain. When codesign tries to use your code signing identity, the system attempts to present the keychain unlock dialog. That fails because you’re logged in via SSH and thus don’t have access to the GUI. The system returns the errSecInternalComponent error to codesign, which reports it to you. To fix this, unlock your keychain using the security tool: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature IMPORTANT This assumes that your code signing identity is in your login keychain. If it’s in some other keychain, read the security man page to learn how to unlock a specific keychain. Best practice is to store both parts of your code signing identity (the certificate and the private key) in the same keychain. If you split the identity across two keychains, unlock the keychain that contains the private key. Test your CI job Once you have everything working on your CI system over SSH, try running exactly the same commands in your CI job. If your CI system manages user contexts correctly, those commands should just work. If they don’t, discuss this with your CI vendor. Note macOS has a complex execution context model. For background on this, see the Execution Contexts section of Technote 2083 Daemons and Agents. Some CI systems don’t correctly establish a user context when running jobs. For example, they might switch the traditional Unix execution context — the EUID, RUID, and so on — but not the security context. This mixed execution context causes problems for the keychain, which relies on the security context. Avoid doing code signing work as root. Some folks run everything as root because they think it’ll avoid problems. When working with the keychain the opposite is true: Running as root often causes more problems than it solves. These problems are most likely to show up when you use sudo, which creates a mixed execution context. Working without the GUI The instructions above assume you have access to the GUI so that you can test and resolve issues using GUI tools like Keychain Access. However, many CI systems don’t give you access to the GUI; at best you might have interactive access using SSH. Note If you CI system allows remote access using a screen sharing protocol, use that rather than messing around with the instructions here. If you don’t have access to the GUI of the machine on which you’re signing code, there are three issues to deal with: Avoiding the keychain unlock dialog Avoiding the ACL dialog Investigating an untrusted code signing certificate issue To unlock the keychain, use the unlock-keychain subcommand of the security tool, discussed in the Test over SSH section earlier. When logged in with the GUI, you can respond to ACL dialog by clicking Always Allow. This prevents that dialog showing up again. However, if you don’t have GUI access there’s no way to click that button. To get around this, import your signing identity and set its ACL to allow codesign to use it without extra authorisation. To do this, first unlock the keychain: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD Then use the security tool to import the PKCS#12 file: % security import IDENTITY.p12 -T /usr/bin/codesign -P P12_PASSWORD 1 identity imported. Note the -T option, which adds codesign to the private key’s ACL. Finally, modify the partition list to allow access by Apple code: % security set-key-partition-list -S "apple:" -l "Apple Development: …" This example assumes you’re using an Apple Development signing identity to test with. If you’re using something else, replace Apple Development: … with that identity name. Finally, investigating an untrusted code signing certificate issue remotely is quite challenging. Your best option here is to set up a local test environment, run your investigation in that environment, and then apply the results to your CI environment. There are two good choices for your local test environment: Use a virtualisation app to create a ‘clean’ macOS guest, one that’s never seen your code signing setup before. Use System Settings > Users & Groups to create a new local user account and do your testing there. The first option is best because you can easily restore your VM to a clean state between tests. When running through the process described in Fixing an untrusted code signing certificate, you might end up performing two different remedial actions: Importing an intermediate Reseting trust settings. Once you understand these remediations, you need to apply them to your CI system. The first one is easy: To import an intermediate, run security with the import subcommand: % security import INTERMEDIATE.cer 1 certificate imported. Resetting trust settings is more of a challenge. It’s probably possible to do this with the security tool but, honestly, if you think that your CI system has messed up trust settings it’s easiest to throw it away and start again from scratch. Terminal failure The bulk of this post assumes that the process described in the Test from Terminal section works. If it doesn’t, something weird is happening and you should apply the following diagnostic suggestions. The first is to create a new local user account on your Mac — using System Settings > Users & Groups — and then retry there. The goal of this test is to isolate: A problem that affects your Mac as a whole From a problem that’s tied to your user account If the problem is with your user account, switch back to your original account and run: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. In most cases this should report that no trust settings were found. If it report trust setting overrides, remove them. See Check for a trust settings override in Fixing an untrusted code signing certificate. If that doesn’t resolve the issue, something else is afoot and I recommend that you seek dedicated help per the start of this post. Revision History 2024-10-05 Added the Terminal failure section. Made other minor editorial changes. 2022-08-12 Extended the unlock-keychain explanation to cover the split identity issue. 2022-08-11 First posted.

I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. IMPORTANT Don’t go down this path if you’ve simply lost your private key. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2025-03-28 Excised the discussion of Xcode’s import and export feature because that was removed in Xcode 16. 2025-02-20 Added some clarification to the end of Don’t Leak Your Private Key. 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

When I make ipa by commond tools,Some errors have occurred.Has anyone encountered it before？ Ps:debug mode is ok，release mode is not ok. error: exportArchive: Code signing "FBAEMKit.framework" failed. Error Domain=IDEDistributionPipelineErrorDomain Code=0 "Code signing "FBAEMKit.framework" failed." UserInfo={NSLocalizedDescription=Code signing "FBAEMKit.framework" failed., NSLocalizedRecoverySuggestion=View distribution logs for more information.}

I am developing a mobile application with Delphi 11. I compiled the application using iOS SDK 17.5. I uploaded it to the Apple Store for testing and first tested it on an iPhone 7 (software version 15.7.1). The application worked smoothly. Later, I tested it on an iPhone 14 (software version 17.6.1) and an iPhone 11 (software version 18). On both of these devices, the application crashed before opening. Since the same application is available on the Apple Store, I downloaded it from there and saw that it worked fine on the last two devices. I thought that the SDK needed to be upgraded for newly compiled and submitted applications. However, in that case, it should have thrown an error when submitting the application to the Apple Store. I updated macOS and Xcode and upgraded to SDK 18. I also set SDK 18 in Delphi. When I compiled with these settings, I again saw that it worked normally on my first device, while the application crashed on the next two devices. Considering it could be an issue with a module in the application, I compiled a blank form by removing all permission requests for testing, but the result did not change. What can I do about this? Do you have any suggestions?

Using .p12 file (included ios developer and ios distribution), to keychain login tried to register iPhone Developer and iPhone Distribution. But iPhone Distribution is not displayed. MacOS: 15.0.1

The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "***" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David

There does not seem to be a way to code sign a PAM module so that an XPC service can verify the signature with setCodeSigningRequirement. There should be a way to build a PAM module (dynamic Library ) so it can be code signed. Put in a bundle and code signing the bundle does not work .

I am a developer, please send me the authentication code !

I was able to setup a release test for an iOS app for distribution using a web server. It works perfectly fine for all the devices I registered for the deployment profile. However every time I try to distribute a Unity based Vision Pro application using the same process for building the package and set up for distribution it does not work. Safari only shows a message telling me: "Cannot connect to ." When trying to install the iOS app from the same server it shows the message "Do you want to install ?" and installation completes correctly. My iOS is a simple hello world app generated by Xcode. My Unity app is an AR app targeting com.apple.platform.xros. According to documentation there should not be any difference in deployment profiles/signing for iOS apps vs. visionOS apps. What am I doing wrong? Any hint is appreciated how to continue.

I have an app Arpeggio.app which I build and then sign without errors: "electron-osx-sign dist/mac-arm64/Arpeggio.app --identity="Developer ID Application: XXXX (XXXXXX)" --hardened-runtime --no-gatekeeper-assess --entitlements=entitlements.plist". It returns "Application signed: dist/mac-arm64/Arpeggio.app". I then use "/usr/bin/ditto -c -k --sequesterRsrc --keepParent src dst" to make a zip with the same signatures. I then submit the zip for notarization: "xcrun notarytool submit dist/mac-arm64/Arpeggio.zip --apple-id XXXX etc" which returns "Waiting for processing to complete. Current status: Accepted.............. Processing complete id: ***-***-xx-xx status: Accepted". Then I staple the notarization to the app and get "The staple and validate action worked!". Now it shows all validated and that the notarization is stapled. I then run "spctl --assess --type execute -vv 'dist/mac-arm64/Arpeggio.app'" as a last check and always get this: dist/mac-arm64/Arpeggio.app: unknown error 99999=1869f Why is this happening? I can't seem to debug the issue but out notarization and signing is always successful and the app works as expected. Pleas ehelp me get to the bottom of this.

Hi, I'm currently developing a Flutter app that utilizes Push Notifications. The Android implementation is working flawlessly, but I'm encountering compilation issues in Xcode. Specifically, I'm receiving the following error: Cannot create a iOS App Development provisioning profile for "dk.ceniconsulting.alarm". Personal development teams, including "Henrik Thystrup", do not support the Push Notifications capability. No profiles for 'dk.ceniconsulting.alarm' were found Xcode couldn't find any iOS App Development provisioning profiles matching 'dk.ceniconsulting.alarm'. This error seems to be a common issue, but I haven't been able to find a definitive solution. I've already generated a certificate, identifier, and installed them, but the problem persists. Does anyone have any insights or suggestions on how to resolve this issue? Or perhaps a link to a resource that addresses this specific problem?

Hi After I added iCloud container and iCloud documents my UITests can't run anymore what is this problem and how can I solve it? Thanks!

Hi, If an Apple developer subscription account is stopped, how does it affect already signed and and notarized apps? Will all apps and dmg's already signed and notarized in the past still be valid in the future?

Hello, I am on maxOS 14.6 and I developed a C++ application for macOS with graphical-user interface by using wxWidgets. The .app application bundle is built correctly and the application runs. Now I would like to sign it to get it notarized. I get the following error sudo codesign -vvv --deep --strict MyApp.app/Contents/MacOS/MyApp MyApps.app/Contents/MacOS/MyApp: code has no resources but signature indicates they must be present If I check the signature I get % pkgutil --check-signature MyApp.app Package "MyApp": Status: package is invalid (checksum did not verify) How may I fix this? Thank you!

App is built using jdk21, jpackage to create dmg, pulls in the needed jre. Been working fine until about a week ago when notarize start failing bad signing, which when examined it's complaining modified files - a handful of jre license and copyright text files. DMGs built, signed and notarised successfully are now failing codesign verification. Has a macOS 15.1.1 release or Xcode 16.1 patched something, is there new behaviour to be aware of plse?

For some reason Xcode said my certificate was revoked. Developer support says it’s active. Could someone point me towards the steps to reactivate it?

note technically code-signing but related...... Why has there been no update to the documentation at: https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device To demonstrate how to validate an SHA256 app store hash ??? The January deadline is looming and I can find no working example code which sucessfully validates an SHA256 hash HELP !!!!

Xcode 16.2 無法在IOS 18.2 Debug Xcode 16.2 iOS 18.2 直接建立新專案 Xcode -> Create New Project -> Multiplatform -> Application -> App 選擇 實體手機 -> 執行 error: attach by pid '1050' failed -- attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.) Logging Error: Failed to initialize logging system due to time out. Log messages may be missing. If this issue persists, try setting IDEPreferLogStreaming=YES in the active scheme actions environment variables.

Chrome has started crashing almost immediately after startup. I've reported the issue to the Chrome team here: https://issues.chromium.org/issues/385433270 I'm hoping to debug the issue a bit more myself. This page from the Chrome team https://chromium.googlesource.com/chromium/src/+/master/docs/mac/debugging.md#chrome-builds suggests using the follow to strip off the protections: codesign --force --sign - path/to/Google\ Chrome.app However, applying that seems to have no effect: % codesign --force --sign - /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed % lldb /Applications/Google\ Chrome\ copy.app (lldb) target create "/Applications/Google Chrome copy.app" Current executable set to '/Applications/Google Chrome copy.app' (arm64). (lldb) run error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)) I have tried other variations like the following based on Stack Overflow, this forum, etc., but with the same result. (I'm still a little vague on the meaning for some flags, sorry.) Though codesign says that it's "replacing existing signature", as far as I can tell, nothing is changing: % cat <<EOF > debuggee-entitlement.xml <?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.security.get-task-allow</key> <true/> </dict> </plist> EOF % codesign --verbose=4 -fs - --options library-validation --entitlements debuggee-entitlement.xml /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed file with invalid attached data: Disallowed xattr com.apple.FinderInfo found on /Applications/Google Chrome copy.app lldb still fails the same way. Here's what I see after the above: % codesign -d -vvv /Applications/Google\ Chrome\ copy.app Executable=/Applications/Google Chrome copy.app/Contents/MacOS/Google Chrome Identifier=com.google.Chrome Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8 CandidateCDHashFull sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b Hash choices=sha256 CMSDigest=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b CMSDigestType=2 CDHash=5d7beab2b03d9892426076b24acc19815d7a3ff8 Signature size=8989 Authority=Developer ID Application: Google LLC (EQHXZ8M8AV) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 17, 2024 at 2:47:58 PM Notarization Ticket=stapled Info.plist entries=44 TeamIdentifier=EQHXZ8M8AV Runtime Version=15.0.0 Sealed Resources version=2 rules=13 files=63 Internal requirements count=1 size=288 From what I can tell, my codesign runs have changed nothing... I see no diff as compared with what I see running codesign -d on a fresh copy. Is it possible to strip off the protections on my local instance to allow debugging with lldb? If so, could someone share a command for accomplishing that? Although I'm asking about this because of Chrome specifically, I'm hoping to learn more about codesigning in general and to be more empowered as a user to be able to debug when an app I depend on is crashing. Thanks much! Happy Holidays!

I want to code radeem for testflight