“codesign”

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

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

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

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)

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

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

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

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

[quote='773573021, Kray16, /thread/773573, /profile/Kray16'] 1. Is using teamID as a signing requirement enough? [/quote] Probably. You might want to tighten that up depending on your specific security goals. For example, you might want your distribution-signed server to not allow development-side clients. For more background on this, and specific info on how Apple uses code-signing requirements in general, see TN3127 Inside Code Signing: Requirements. [quote='773573021, Kray16, /thread/773573, /profile/Kray16'] 2. How does xpc_connection_set_peer_code_signing_requirement work internally? [/quote] The exact mechanics of this are complex, but you can reasonable think of it as checking the requirement against the calling process. This is a code signing operation. You can prototype it with codesign, using the --verify subcommand. Two hints: A little known fact is that you can get codesign to operate on a process by supplying a PID as an argument. TN3127 shows how to request that codesign

Usually I just download them all (-: The system is good at finding intermediates that it needs and ignoring any extras. However, as you’re asking, the one you’re looking for is Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC). If you download that and Quick Look it in the Finder, you’ll see its Subject Name details match the Issuer Name details from your screen shot. On the installation front, adding it to your login keychain should be fine. The system doesn’t need this intermediate to verify code [1], it only needs it to sign code. And you do that from your user context, which has access to your login keychain. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] When you sign code the codesign embeds the complete certificate chain into the code signature. This has two consequences: The system verifying it has all the certificates it needs to do that verification. The system doing the signing needs the intermediate, which is why

Hi Quinn, I can confirm that loading the dylib when it is copied into the app bundle works correctly, so it seems like it is not a codesigning issue but rather from where the dylib is loaded. Interpreted code is unfortunately not an option because this is for rather high performance code. Wasm could be a possibility but as far as I can see there is no functionality in iOS to execute wasm code inside of an iOS app. Can you give some more details on what holes in the firewall Xcode punches for development purposes. Maybe some of that could be used for a better dev workflow on iOS.

Thanks for that. I downloaded your app and was able to sign it just fine: % sw_vers ProductName: macOS ProductVersion: 15.2 BuildVersion: 24C101 % % codesign -s - -f ALP_Document_Factory_II .app ALP_Document_Factory_II .app: replacing existing signature The one thing I noticed is that your app name contains weird characters. Note the ‘gaps’ in the shell completed name above. Now consider this: % ls | xxd 00000000: 414c 505f 446f 6375 6d65 6e74 5f46 6163 ALP_Document_Fac 00000010: 746f 7279 5f49 49c2 a0c2 a02e 6170 700a tory_II.....app. 00000020: 414c 505f 446f 6375 6d65 6e74 5f46 6163 ALP_Document_Fac 00000030: 746f 7279 5f49 49c2 a0c2 a02e 7a69 700a tory_II.....zip. Each c2 a0 sequence is a U+00A0 NO-BREAK SPACE. Did you add those deliberately? If not, I recommend that you remove them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com