Hello, I have been implementing faceID authentication using LocalAuthentication, and I've noticed that if i use swift 5 this code compiles but when i change to swift 6 it gives me a crash saying this compile error: i have just created this project for this error purpose so this is my codebase: import LocalAuthentication import SwiftUI struct ContentView: View { @State private var isSuccess: Bool = false var body: some View { VStack { if isSuccess { Text("Succed") } else { Text("not succeed") } } .onAppear(perform: authenticate) } func authenticate() { let context = LAContext() var error: NSError? if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) { let reason = "We need to your face to open the app" context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) { sucexd, error in if sucexd { let success = sucexd Task { @MainActor [success] in isSuccess = success } } else { print(error?.localizedDescription as Any) } } } else { print(error as Any) } } } #Preview { ContentView() } also i have tried to not use the task block and also gives me the same error. i think could be something about the LAContext NSObject that is not yet adapted for swift 6 concurrency? also i tried to set to minimal but is the same error Im using xcode 16.1 (16B40) with M1 using MacOS Seqouia 15.0.1 Help.

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?

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!

Hello, I'm new at developing an ios app, but I have created a basic app, I plan to use just for me using xcode and the language swift. I intend to use this app, to display a video and images on ipads that will be used as KIOS on a trade show. I don't need this app to be published on the app store as I intend to use it solely for my use. Is there a way I can do something like this that won't be restricted with the 10 days restriction? I learned xcode/swift as little as I could to create the app, but now I'm limited to the 10 days, and only 3 devices. Is there a way I can create an offline app, that doesn't have the all the restrictions? I plan to use these ipads over and over again on tradeshows to display my work.

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run syspolicy_check like this: % syspolicy_check distribution WaffleVarnish.app This tool was introduced in macOS 14. On older systems, use the older spctl tool. Run it like this: % spctl -a -t exec -vvv WaffleVarnish.app Be aware, however, that this check is much less accurate. Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle This command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-12-05 Added instructions for using syspolicy_check. Made other minor editorial changes. 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

I am working on releasing my macOS arm64 app. My problem is that after the user downloads the dmg, double-clicking my.app in the dmg, a Gatekeeper pop-up box will appear with a warning that the developer cannot be verified. Question: Can an application signed with "com.apple.security.cs.disable-library-validation" be published as trusted? If yes, what steps have I missed? If not, can I get an official response from Apple? （Because I referred to this post, it seems to mention that it is possible to publish trusted software.I have looked up similar questions on the forum and tried many things, but nothing works. ） Here are my steps: Use the codesign to sign my.app. Because my app needs to access third-party dynamic libraries, entitlements.plist contains a "com.apple.security.cs.disable-library-validation". After the "codesign -dvvv" check, the signature was successful.✅ Use the "xcrun notarytool" command to notarize my app, and the status is displayed as accepted.✅ Use "xcrun stapler staple" to attach the notarization to my app, and it returns success.✅ Use the "spctl -a -v " command to verify whether my app has passed Gatekeeper, and it returns that it has passed.✅ Then I packaged my.app into a dmg, and then attached the notarization mark to the dmg, which was successful.✅ I completed the above steps and distributed the dmg. When I downloaded the dmg as a user test and double-clicked my.app in it, the Gatekeeper pop-up box still appeared, and the developer cannot be verified.❌

Platforms: Ventura and Big Sur Steps to Reproduce: Create new application and installer CSRs with keypairs Generate new certificates in Apple web portal Repackage certificates as .p12 using exported private keys since they are not referenced in keychain app by default. Import certificates into MacOS Keychain Set certificate access to "Always Trust" for all certificate uses Sign binary fails using "codesign --force --sign " Sign installer package succeeds using "productsign --sign Additional Info: The private keys ware initially not recognized by the Keychain application resulting a certificate without a private key "leaf" beneath them. To resolve it I exported the private key and repackaged certificate as a .p12 file. Both certificates appear "good" when evaluated for code signing The installer certificate shows an intermediate and root while the application certificate does not Repackaging as .p12 with expected intermediate and root did not resolve the issue Installing all available intermediates and roots from Apple did not resolve the issue Signing a test app with XCode succeeds In production, we sign using CMake so we need to be able to sign code from the command line with codesign.

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?

I have already posted asking about this: [quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Codesigned and notarized app cannot directly write files inside the app bundle... [/quote] But there are still some doubts that have not been answered. We use Qt to develop an application on the macOS platform, and we are attempting to perform code signing and notarization to ensure our the application is trusted by Apple. However, there are a few things that seem weird regarding this statement: "App bundles are read-only by design." Let me provide more details. Currently, when our application starts, it needs to create folder (e.g. Temp) in the root directory of the executable For example: Myapp.app/Contents/MacOS/Myapp ---> Myapp.app/Contents/MacOS/Temp The folder is designed for storing runtime logs or config files for our application. In the past, users may also modify the settings inside target folder if needed. However, the strange thing is that after the application is codesigned and notarized. When we double-click the application Myapp (a.k.a Myapp.app) in Finder, it could successfully launch and create the Temp folder inside the Myapp.app/Contents/MacOS folder. However, when we navigate and attempt to run the main application executable in command line mode (as our application supports this command line execution) $ cd Myapp.app/Contents/MacOS $ ./Myapp -h As our application will check if the root folder has write permission before starting (i.e., check if Myapp.app/Contents/MacOS is writable because we require to create Temp folder in the following steps) It pop up the error that folder does not have write permission. The aforementioned scenarios seems to conflict with this statement: "App bundles are read-only by design" (because when the application is launched directly by clicking in Finder, the Temp folder can be created successfully, but via the console command line, it cannot). I would like to confirm again if writing files in the notarized application MacOS directory is not allowed? If not, have any recommended approaches? (e.g., changing the folder to another directory). What causes the different results in these running scenarios? We are not concerned about breaking the signature after application launched, as it seems that macOS will add it to system trust list after first time successfully launch. (Download the app from internet --> System: it is an app downloaded from the internet. Are you sure want to open it...? OK --> Although our application creates the Temp folder after first launch, when we click the application second time, it could directly open the app)

Adobe says that Animate works with the latest Mac OS. When I publish apps with Animate, they work on my computer. With a self-signed certificate, they work on some older Mac OS versions, but not on the 2 most recent. How can I test my apps on others' Mac computers? Robert

I work with a team that is responsible for our company's centralized infrastructure for code signing various products within our portfolio, including iOS apps. For security purposes, we want to sign apps before their posting on the App Store, and also to log this activity for eventual security audits. Not surprisingly, we need automated processes; we can't use an IDE like Xcode to do the work. We must queue, process, and log all signing jobs, and have Macs dedicated to this purpose. I can't go into many details about our infrastructure due to confidentiality concerns, so I'll apologize now if my questions seem a little vague. We currently require our iOS developers to submit one or more new provisioning profiles as well as their IPA archive for signing. We support supplying multiple provisioning profiles because some of our developers include embedded third-party extensions within their IPAs, and these extensions can also have their own provisioning profiles. Within our back end, we open the archive, sign the relevant portions using the entitlements in one of the profiles (that we believe to be the appropriate one for the particular archive element), overwrite each supplied provisioning profile with (what we believe to be) the appropriate one from user input, and re-compress the archive. Here come the questions: When we receive multiple provisioning profiles, how do we know which profile should be used to help with signing which archive elements? What data (e.g. entitlements application-identifier, team-identifier) can we use? We also need to know which provisioning profiles from their input correspond to those that already exist within the archive. What data can we use to map profiles from one set to the other? Should we be requiring our users to submit new provisioning profiles in the first place? Or should we edit/recycle the existing ones in some way? We'd like to remove any unnecessary burdens for our users, if possible.

I'm unable to run a widget containing a live activity with the error message at the bottom of this post. I've verified I have NSSupportsLiveActivities set to yes in the correct Info.plist, and have downloaded sample projects from github containing the same values. This error occurs while running on a device or simulator, on Xcode 15 and 16, iOS simulator 17 and 18. Create sample project Create new widget extension target Set NSSupportsLiveActivities to true in the appropriateinfo.plist Run the widget This seems to be a longstanding issue https://forums.developer.apple.com/forums/thread/651611 Any ideas for debugigng? I'm completely blocked from running live activities. SendProcessControlEvent:toPid: encountered an error: Error Domain=com.apple.dt.deviceprocesscontrolservice Code=8 "Failed to show Widget 'ca.holligan.live-activity-example.widget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}." UserInfo={NSLocalizedDescription=Failed to show Widget 'ca.holligan.live-activity-example.widget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}., NSUnderlyingError=0x600000c6a940 {Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}}} Domain: DTXMessage Code: 1 User Info: { DVTErrorCreationDateKey = "2024-11-15 17:06:33 +0000"; } SendProcessControlEvent:toPid: encountered an error: Error Domain=com.apple.dt.deviceprocesscontrolservice Code=8 "Failed to show Widget 'ca.holligan.live-activity-example.widget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}." UserInfo={NSLocalizedDescription=Failed to show Widget 'ca.holligan.live-activity-example.widget' error: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}., NSUnderlyingError=0x600000c6a940 {Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open "com.apple.springboard" failed." UserInfo={NSLocalizedFailureReason=The request was denied by service delegate (SBMainWorkspace)., BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x600000c6a8b0 {Error Domain=SBAvocadoDebuggingControllerErrorDomain Code=1 "Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)" UserInfo={NSLocalizedDescription=Failed to get descriptors for extensionBundleID (ca.holligan.live-activity-example.widget)}}, FBSOpenApplicationRequestID=0x2ca0, NSLocalizedDescription=The request to open "com.apple.springboard" failed.}}} Domain: DTXMessage Code: 1 System Information macOS Version 14.5 (Build 23F79) Xcode 16.1 (23503) (Build 16B40) Timestamp: 2024-11-15T12:06:33-05:00

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?

I tried building the React App for Any iOS device (Arm64) but I get error. Although I can build successfully for any iOS Simulators In the codesigning step I get the following error, "Warning: unable to build chain to self-signed root for signer "Apple Development: my email address ( ... ) " I don't have paid membership of Apple Developer Program, does that cause this failure? Also, to archive also do I need Apple Developer Program paid membership?

Project Background: I developed a Mac project using Electron and VSCode Successfully uploaded the packaged pkg using Transporter, However, I will receive an email informing me that there are some issues with the project: ITMS-90296: App sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' Here is my packaging process: Generate an app using the electron packager tool Sign the app using @ electron osx sign (version 1.3.1) After signing, use productbuild - component Yourappname App/Applications - sign "3rd Party Mac Developer Installer: * * * * * (XXXXXXXXXX)" Yourappname. pkg command generates pkg PS： For the second step, I have set sand box=true in both entitlents.plist and entitlents.macinheriting. plist. And after signing, using codesign -dvvv -- entitiements - /path to view the app file shows' checkbox=true ', and the [iFlytek Listen. app/Contents/MacOS/iFlytek Listen] file in the issue also exists. Using the Suspicious Package software to view pkg also has sandbox=true. A few months ago, I uploaded it once and the issues mentioned in the email did not appear. The only changes were the macOS system version number and the replacement of the signature with provisionprofileprovisionprofile. I have reviewed similar issues on the Apple Developer Forums, but have not been resolved

In the past, I used to export a developer-signed test version of my macOS app in Xcode, create a zip archive from the Finder, upload it to my website and share the link to the testers. The last time I did this with macOS 14 the tester was still able to download the test app and run it. But it seems that with macOS 15 the trick to open the context menu on the downloaded app and click Open to bypass the macOS warning that the app couldn't be checked when simply double-clicking it, doesn't work anymore. Now I'm always shown an alert that macOS couldn't check the app for malware, and pushes me to move it to the bin. In this StackOverflow topic from 10 years ago they suggested to use ditto and tar to compress and uncompress the app, but neither worked for me. How can I share macOS apps that I signed myself with testers without physically handing them a drive containing the uncompressed app?

Codesigned and notarized app cannot directly write files inside the app bundle (neither in my.app/Contents/Resources/ nor my.app/Contents/MacOS/). Are there any restrictions regarding this? Is there a way to bypass these restrictions? Here is the situation I encountered: The main app contains several sub-apps and sub-executables. When the main app calls the sub-apps or sub-executables, it can write files within the app bundle, but when executed directly, it cannot write files. The app is usually opened using the GUI, and when using the command line, neither the main app nor the sub-apps/sub-executables can write files within the app bundle. My codesigning environment is: Sonoma 14.0 on mac mini M1. I manually sign the app directly using the codesign command in CI instead of using Xcode. The process will traverse all of the files and sub-apps in the app folder and sign them from the deepest paths to the shallowest paths. I also tried applying this process to other applications, but all of them encountered the same issue of failing to write files. The app should not be sandboxed (I did not add sandbox entitlements). I have tried adding the entitlement com.apple.security.files.user-selected.read-write, but this has not resolved the issue.

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.

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.