codesign

[quote='848428022, intown, /thread/792209?answerId=848428022#848428022, /profile/intown'] Is there anyway I can get some assistance. [/quote] It’s hard to say without knowing more about the problem you’re experiencing. If this is a technical problem, then I recommend that you open a new thread here on the forums with the details [1]. Please pay careful attention to the topic, subtopic, and tags you choose, because many of us use that info to find relevant questions. For more info on how to use the forums effectively, see Quinn’s Top Ten DevForums Tips. OTOH, if this is a non-technical problem then the Apple Developer Forums might not be the right option. In that case, post a short summary of the issue here and I’ll see if I can offer a path forward. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Unless the problem happens to be about codesigning timestamps on IPv6 networks in Europe, but that seems unlikely. But, hey, if it doe

I want to be clear about terms here: A bundle ID is how the system uniquely identifies your app. It’s typically in reverse DNS format, for example, com.apple.iWork.Pages. An App ID is composed of an App ID prefix and a bundle ID. For example, 74J34U3R6X.com.apple.iWork.Pages. The App ID prefix is typically your Team ID, but iOS previously used to require unique App ID prefixes, where you allocate a prefix that’s different from your Team ID. The apple-app-site-association file is expecting App IDs. There’s no ambiguity there. For any given App ID, the prefix is either the Team ID or a unique value. There are plenty of ways to determine your App ID but my preferred option is: Using Xcode, build your app for the device. Using Terminal, dump its entitlements: % codesign -d --entitlements - /path/to/your.app Look for the application-identifier entitlement (com.apple.application-identifier for Mac apps). If your app is currently using a unique App ID prefix, there are good reasons to convert it to use your

fidelisevents % syspolicy_check distribution ./bin/FidelisEvents.app/Contents/MacOS/fidelisevents App passed all pre-distribution checks and is ready for distribution. fidelisevents % syspolicy_check distribution ./bin/FidelisEvents.app App passed all pre-distribution checks and is ready for distribution. And yes, I did this after removing the negative flags in the entitlement: codesign -d --entitlements :- ./fidelisevents.app Executable=/Users/darrelburns/devel/fidelisevents/bin/FidelisEvents.app/Contents/MacOS/fidelisevents warning: Specifying ':' in the path is deprecated and will not work in a future release Current Status: I’ve followed all documented Apple and forum guidance for deploying a non-system-extension Endpoint Security client as a Developer ID app bundle. I have: Embedded a Developer ID Application provisioning profile with the Endpoint Security entitlement (confirmed by developer.apple.com, profile XML, and all tools). Used codesign, spctl, and syspolicy_check distribution (

Of course, that doesn't change the fact that codesign has no useful diagnostics, and does a horrible job of cleaning up after itself.... 😄

After learning that Endpoint Security (ES) clients must be packaged in an “app-like” structure to use a provisioning profile, I followed Apple’s technical note and Quinn’s advice: Steps Taken App Bundle Creation Created a bundle named FidelisEvents.app, with standard macOS .app layout. Placed my universal Mach-O (x86_64/arm64) binary at FidelisEvents.app/Contents/MacOS/fidelisevents. Added an Info.plist at FidelisEvents.app/Contents/Info.plist with the correct CFBundleIdentifier and metadata (matching the provisioning profile/App ID). Provisioning Profile Embedded the provisioning profile at FidelisEvents.app/Contents/embedded.provisionprofile. Profile type: Developer ID Application for macOS. App ID and team identifier match the bundle and entitlements. Profile entitlements explicitly include: com.apple.application-identifier com.apple.developer.team-identifier com.apple.developer.endpoint-security.client Confirmed by extracting and inspecting the embedded profile. Entitlements Used an entitlements plist at

My initial post was not very clear, adding some supporting information below: Initial NFC session establishes successfully Failure occurs immediately on first APDU transmission Configuration & Verification: Xcode Capabilities: Near Field Communication Tag Reading is enabled in the target's Signing & Capabilities tab. entitlements File: com.apple.developer.nfc.readersession.formats is correctly set to an array containing only TAG. (Confirmed ISO7816 should NOT be directly in this array based on Apple documentation). com.apple.developer.nfc.readersession.formats TAG Info.plist Configuration: Privacy - NFC Scan Usage Description (NFCReaderUsageDescription) is present. com.apple.developer.nfc.readersession.iso7816.select-identifiers is correctly configured with an array of relevant YubiKey AIDs, including the OATH AID (A000000527210101) and others. codesign Output : After building the app, running codesign -d --entitlements :- /path/to/YourAppName.app explicitly confirms that the com.app

This is the line I was adding to /etc/pf.conf on every reboot: block drop from any to 2620:149:981:603::10 ETA: I want to be clear that the ridiculous part is that it's been going on for over a year, that I never got any response even after I mentioned in at least one forum comment that it was still occurring here, and that codesign after decades continues to give no error messages on failure. Oh, also that it doesn't clean up the .cstemp files it leaves behind, which admittedly were the only clue I had what was going on.

[quote='791565021, thornhill_medical, /thread/791565, /profile/thornhill_medical'] After I package/codesign into a hardened runtime, I start seeing crashes at the moment when I try to execute the system calls to Docker. [/quote] I have some general advice on this front in my Resolving Hardened Runtime Incompatibilities post, part of the Resolving Trusted Execution Problems series. If you post a crash report, I might be able to offer more specific advice. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks so much for the response! clang and rustc (by design on Rust' part, to be clear!) are sufficiently similar that it was pretty easy to translate between C++ and Rust! Your tips/suggestions almost worked for me, except that the binary would be sigkilled'd immediately after launch. I did some rubber-duck debugging using Claude, and it—rather impressively!—pointed out in https://claude.ai/share/5a4ca3ca-9e98-4e2a-b9ae-71b49c6983cf that the entitlement I needed to use was com.apple.security.get-task-allow, not com.apple.security-get-task-allow. Instruments' diagnostic contained a typo! Once I fixed this typo, I was able to use the Processor Trace instrument via xctrace. Of course, since this is beta software, which I hit a few bugs, which I'll cover at the end of this post. Apple silicon code must be signed, so the linker automatically applies an ad-hoc signature. You can see this if you dump the hello tool before re-signing it: [dump redacted] If you’re going to re-sign the binary anyway, you can disable l