Hi, I have a project that integrates the Firebase SDK via SPM as a dependency of an internal Swift Package: My app ⟶ My Library ⟶ Firebase SDK The project builds successfully and can be archived locally ✅. The uploaded .ipa is valid and gets published 🚀. However, we are now trying to automate the release process using Xcode Cloud, but the iOS Archive action is failing ❌ on Xcode Cloud. The logs show the following error ⬇️: error: exportArchive codesign command failed (/Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: replacing existing signature /Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: invalid or corrupted code requirement(s) Requirement syntax error(s): line 1:178: unexpected token: ) ** EXPORT FAILED ** I have been researching this issue for a while and have tried several solutions to fix it, but with no luck. Even thoug
Search results for
codesign
3,112 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I have an app that only crashes once it's been notarised. I read a few posts that essentially said before trying to identify issues by reviewing the crash report I should ensure signing and notarisation has happened correctly. I've worked through the document Resolving common notarization issues spctl -vvv --assess --type exec: gives no errors and correctly returns my developer id. codesign -dvv: returns a timestamp My app uses a hardened runtime. My app shows up in Xcode as a macOS Archive (e.g not a Generic Xcode Archive) Here is the crash report. Translated Report (Full Report Below) Process: Scene Finder [44479] Path: /Users/USER/Downloads/Scene Finder.app/Contents/MacOS/Scene Finder Identifier: Version: 0.9 (20250206.1) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-02-11 13:09:03.7786 +1000 OS Version: macOS 15.3 (24D60) Report Version: 12 Anonymous UUID: EE8B1269-0A8A-3AB6-516B-C752E8A18B5A Sleep/Wake UUID: 436CD7CF-7B13-4A9C-9425-7EF94CC007A9 Time Awake Si
I am a new macOS developer, and the codesign issue is persistent. I've been trying to resolve it for days. There are two issues: 1.) When downloading and installing frameworks, they are not showing up in Xcode templates. 2.) Regarding codesigning, even though I've installed it on my external drive and placed it in various locations (Library, Templates, Frameworks, Application Contents, macOS Templates and Frameworks) and added through General Libraries in Xcode, persistently encountering issues. I'm experiencing a codesign problem. I've cleaned the build, cleared derived data, downloaded certificates, added them to the access key, and linked the binary. However, the issue persists. Please help me, as this is making the process much more difficult. I've been stuck on this for weeks.
Topic:
Code Signing
SubTopic:
General
On my MAC, I have a XPC server running as a daemon. It also checks the clients for codesigning requirements. I have multiple clients(2 or more). Each of these clients periodically(say 5 seconds) poll the XPC server to ask for a particular data. I want to understand how the performance of my MAC will be affected when multiple XPC clients keep polling a XPC server.
We are not using NSEndpointSecurityEarlyBoot. None of the calls into Apple frameworks that we've seen lead to killing the extension are during our extension initialization. They're all in response to some event, e.g., ES_EVENT_TYPE_AUTH_MOUNT calls into DiskArbitration, ES_EVENT_TYPE_AUTH_OPEN calls into Security. Important to note: we only care about those OPEN events for a restricted set of paths (our files) and immediately return ALLOW for anything else. The stack you posted is a standard example of what I described here: ...If you call an API that generates auth requests to you and you fail to process those auth requests, then you'll deadlock yourself and the system will kill you. That is, your code is running on directly in the event delivery callback: 34 com.redacted.EndpointSecurity 0x100434284 0x100430000 + 17028 35 libEndpointSecurity.dylib 0x19af7d7d0 BBReader::handleItems() + 356 36 libEndpointSecurity.dylib 0x19af7d558 BBReader::woke(void*) + 28 37 libdispatch.dylib 0x1881c0400 _dispatch_client_ca
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
Hello, Now we support Apple applications and we are building applications on Mac laptops with regular updates. Our goal is to build an iOS app entirely through the command line using xcodebuild and other tools from Xcode Command Line Tools on a server with _macOS Sonoma (14.6.1) without a graphical user interface (only the command line)!!! We need to build and regularly update iOS applications on clients and our accounts and we are looking for a solution to fully automate the login process for these accounts. Our goal is to automate these processes on a server without involving a customer. Here’s what I need help with building and signing the app: What are the proper commands to build and sign the app using xcodebuild and put this application in Apple Store? Server has: xcode-select -version xcode-select version 2408. xcodebuild -version Xcode 16.1 Build version 16B40. In the first step, the certificates have been added to the keychain. We have two keychains. We can check it by running the command: security l
Topic:
Developer Tools & Services
SubTopic:
Xcode
Hi Kevin. Thanks for your detailed reply. We are not using NSEndpointSecurityEarlyBoot. None of the calls into Apple frameworks that we've seen lead to killing the extension are during our extension initialization. They're all in response to some event, e.g., ES_EVENT_TYPE_AUTH_MOUNT calls into DiskArbitration, ES_EVENT_TYPE_AUTH_OPEN calls into Security. Important to note: we only care about those OPEN events for a restricted set of paths (our files) and immediately return ALLOW for anything else. Here is a lightly redacted crash log: Process: com.redacted.EndpointSecurity [492] Path: /Library/SystemExtensions/*/com.redacted.EndpointSecurity Identifier: com.redacted.EndpointSecurity Version: v2.10.0-21-g35018b949c-dirty (58)Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2025-02-04 12:18:33.7447 -0500 OS Version: macOS 13.6.7 (22G720) Report Version: 12 Anonymous UUID: 6570580F-1EF2-E6B5-E10B-CA9F00455210 Time Awake Since Boot: 58 seconds System Integrity Protection: enabled Cras
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
The Authority fields displayed by codesign are simply a summary of the subject of each certificate in the chain. If you want to check that, check the certificate fields. However, you’re much better off requiring a ValidationCategory of .developerID and a specific Team ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
I removed all existing Apple Development keys, added a new one 2/5/25 via ManageCertificates from Accounts in Xcode, the keyChain still tell me the newly pulled Apple Development certificate is not trusted, my system time is fine the expire time of the certificate is 2026, Is it possible the develop certificate issues server has bug? Issued by: Apple Worldwide Developer Relations Certification Authority Expires: Thursday, February 5, 2026 at 8:11:07 AM Mountain Standard Time =========================== steventang@Mac-mini ~ % codesign -s Apple Development: Steven Tang (4XXXXXX4) -f MyTrue MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer Apple Development: Steven Tang (4XXXXXXX4) MyTrue: errSecInternalComponent
Topic:
Code Signing
SubTopic:
General
Tags:
I got steventang@Mac-mini ~ % codesign -s Apple Development: Steven Tang (4XXXXXXX4) -f MyTrue Apple Development: Steven Tang (4XXXXXX4): ambiguous (matches Apple Development: Steven Tang (4XXXXXX4) and Apple Development: Steven Tang (4XXXXXXX4) in /Volumes/TwoTSSD/steventang/Library/Keychains/login.keychain-db)
Topic:
Code Signing
SubTopic:
General
Tags:
I’m confused by your latest posts, in that that they suggest two different errors: unable to build chain to self-signed root for signer Automatic signing failed Xcode failed to provision this target Are you getting both of these errors? Regardless, I recommend that you run a quick test with codesign: % cp /usr/bin/true MyTrue % codesign -s Apple Development: Quinn Quinn (EW7W773AA7) -f MyTrue MyTrue: replacing existing signature replacing Apple Development: Quinn Quinn (EW7W773AA7) with the code-signing identity from your example. Does that work? IMPORTANT After you sign this code it won’t run; we’re just testing the signing here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic:
Code Signing
SubTopic:
General
Tags:
Verified for code sign and Notarisation as below: prjadhav@dhcp-10-180-186-174 Downloads % codesign -v -vvv --strict --deep issue_avoidance_mac issue_avoidance_mac: valid on disk issue_avoidance_mac: satisfies its Designated Requirement prjadhav@dhcp-10-180-186-174 Downloads % prjadhav@dhcp-10-180-186-174 Downloads % codesign -d -vvv issue_avoidance_mac Executable=/Users/prjadhav/Downloads/issue_avoidance_mac Identifier=issue_avoidance_mac Format=Mach-O thin (x86_64) CodeDirectory v=20400 size=855 flags=0x0(none) hashes=21+2 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=071855ea2dc635ef0c42896888239d623a48bea5 CandidateCDHashFull sha256=071855ea2dc635ef0c42896888239d623a48bea562fa83450dedb07df06fb383 Hash choices=sha256 CMSDigest=071855ea2dc635ef0c42896888239d623a48bea562fa83450dedb07df06fb383 CMSDigestType=2 CDHash=071855ea2dc635ef0c42896888239d623a48bea5 Signature size=9010 Authority=Developer ID Application: Oracle America, Inc. (VB5E2TV963) Authority=Developer ID Cert
Topic:
Code Signing
SubTopic:
General
Tags:
Unfortunately, it won't fix my issue, in my case, all items in Key Chain certificates are green, and the code sign is valid steventang@Mac-mini ~ % security find-identity -p codesigning Policy: Code Signing Matching identities DC4B46A359AF226XXXXXXXXXXXXXXXXXXD Apple Development: Steven Tang (XXXXXXX) 1 identities found Valid identities only DC4B46A359AF226XXXXXXXXXXXXXXXXXXD Apple Development: Steven Tang (XXXXXXX) 1 valid identities found ========================== But when I build project, still get unable to build chain to self-signed root for signer Apple Development: Steven Tang (XXXXXXX) /Volumes/TwoTSSD/steventang/Library/Developer/Xcode/DerivedData/XXXX-ddbilgyraofrdyfeljyuknusunza/Build/Products/Release/XXXX.app: errSecInternalComponent I signed out and signed in again, remove account and add again, the problem is still happening. BTW, this problem happened only after I upgraded macOS to 15.3, before upgrading(15.2), I don't have this issue, I supposed there would be an Xcode 16.3 but it is
Topic:
Code Signing
SubTopic:
General
Tags:
First, off I want to focus on these details: Mounting SMB and AFP shares always works without issues. The app is properly sandboxed. and this error: System Policy: webdavfs_agent() deny(1) file-mount ...I don’t see any reason why they would affect only WebDAV mounting while everything else works fine. Agreed. Please file a bug on this and then post the bug number back here. Setting all other issues aside, I can't think of any case where the system should deny mounting for webdav but allow SMB/AFP. This is a case where they should either all fail or all succeed. Next a few clarification on other points: I’d prefer not to recreate all my certificates and configurations, as I don’t see any reason why they would affect only WebDAV mounting while everything else works fine. For future reference, there's generally not any reason to bother with this sort of recreate everything. You can basically split our codesigning architecture around two questions: Is the signature valid? -> If it is, let the code run
Topic:
App & System Services
SubTopic:
Core OS
Tags:
I have created a XPC server and client using C APIs. I want to ensure that I trust the client, so I want to have a codesigning requirement on the server side, something like - xpc_connection_set_peer_code_signing_requirement(listener, anchor apple generic and certificate leaf[subject.OU] = 1234567) This checks if the client code was signed by a code-signing-identity issued by Apple and that the teamID in the leaf certificate is 1234567. My questions are- Is using teamID as a signing requirement enough? What else can I add to this requirement to make it more secure? How does xpc_connection_set_peer_code_signing_requirement work internally? Does it do any cryptographic operations to verify the clients signature or does it simply do string matching on the teamID? Is there a way actually verify the clients signature(cryptographically) before establishing a connection with the server? (so we know the client is who he claims to be)
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
XPC
Signing Certificates
Code Signing