“codesign”

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

I’m not able to help you with third-party tools, so I’m going to base my response on how you would achieve this goal when using Clang directly from Terminal. I’m hoping that you can map this to your third-party tooling. Also, I’m basing my response on the trivial test case described in Investigating Third-Party IDE Integration Problems. The final point of that is a built executable with no entitlements: % codesign -d --entitlements - hello Executable=/Users/quinn/Test/hello % To add the get-task-allow entitlement, first create a property list with the right values: % plutil -create xml1 hello.entitlements % plutil -insert 'com.apple.security.get-task-allow' -bool true hello.entitlements % cat hello.entitlements … com.apple.security.get-task-allow Note Entitlement files are XML property lists. While you can edit these as text, I generally recommend that you use our tools (plutil and also PlistBuddy; both have man pages) because it’s easy to mess things up if you edit them by hand. Now re-sign the

The jpackage command tool provided by Oracle: It specifies some options for MacOS code signing: --mac-sign --mac-package-signing-prefix ST_DFG2D_ARM --mac-signing-key-user-name Pierre Bierre that it reformats when it runs and calls Apple's codesign. Maybe you can show me how to translate these options into a discrete call to codesign? [14:06:05.820] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: Pierre Bierre (SL7L4YU8GT), -vvvv, --timestamp, --options, runtime, --prefix, ST_DFG2D_ARM, /var/folders/v7/06pp2_5d6gz9593k96n2z0v40000gn/T/jdk.jpackage8264959517592888307/images/image-10714515757680011645/DataflowGeometry2D.app/Contents/runtime/Contents/Home/lib/libnet.dylib] exited with 1 code I tried this guess: codesign --sign Pierre Bierre (SL7L4YU8GT) --force --options runtime --verbose --timestamp ~/DFG2D_MacOS_Manufacturing/MacOSInstallers/DFG2D_Mac_J17010_295 The response was: error: The specified item could not be found in the keychain. Not

codesign -d --entitlements - /Users/zhanghai/Library/Developer/Xcode/Archives/2025-06-26/Device Guard 2025-6-26, 11.00.xcarchive/Products/Applications/Device Guard.app Executable=/Users/zhanghai/Library/Developer/Xcode/Archives/2025-06-26/Device Guard 2025-6-26, 11.00.xcarchive/Products/Applications/Device Guard.app/Contents/MacOS/Device Guard [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.device.bluetooth [Value] [Bool] true [Key] com.apple.security.device.usb [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] com.apple.security.network.server [Value] [Bool] true I guess the problem is with step 1. So what can i do for the problem? Thank you for much!

OK. The .entitlements file is source code. Xcode does a lot of processing on its content before it passes it along to codesign to apply to your app. So it’s not uncommon to see problems like this. Most folks upload there app in two stages: Choose Product > Archive to create an Xcode archive (.xcarchive) of the app. In the Xcode organiser, select that archive and click Distribute App to actually upload the app. Are you doing that here? If so, the Xcode archive makes a good test point, that is, you can dump the entitlements in the archive to see if they’re correct. If they are, you know that the problem was with step 2. Alternatively, if the entitlements in the archive are wrong, you know the problem is with step 1. To dump the entitlements in the archive: Select it in the Xcode organiser. Control click and choose Show in Finder. In Terminal, dump the entitlements of the enclosed app. For example, here’s what I see in step 3 for a test app I created in my office: % codesign -d --entitlement

[quote='790330021, pbierre, /thread/790330, /profile/pbierre'] The error feedback from codesign is nonspecific and inactionable. [/quote] Looking at the log you posted I don’t actually see any error information from codesign. It seems that your tooling runs codesign which then exits with status 1, and that’s it. Normally when codesign fails it prints something to stderr. Is that not the case here? Or did it print something but it’s not in the log you included? ps My best guess, based on the info you included, is that this error will be something like this: % codesign -s …all your other arguments elided… libnet.dylib libnet.dylib: is already signed That’s due to a subtle difference between Intel and Apple silicon. On Apple silicon all code is signed by default. If you using an open source toolchain to build your code then it gets ad-hoc signed by the linker. That means that, when you go to sign it, the signing fails because it’s already signed, and hence this error.

I am still digesting that, but I was about to upload another sysdiagnose -- this one from a githubs action VM that demonstrated the same behaviour (but which was a clean install of our app). There was a sysdiagnose from macOS 13.7.6 uploaded which I did look over. Unfortunately, that appears to be a different issue, as sysextd is actually crashing before before it starts authorizing. This does appear to be a known issue (r.99777199), however, there haven't been really been reports post-macOS 13. If you're seeing this crash on more recent releases then that's worth further investigations/bugs, but I don't think there's a lot to be done on macOS 13. Each build gets a new number; for annoying reasons, the build is done twice (Apple Silicon and Intel), lipo'd together, and then codesigned again. For what it's worth, I don't actually have any problem with incrementing all component versions, even when a give component doesn't change. Given the possible complexity of component interactions, it's entirely p

I am still digesting that, but I was about to upload another sysdiagnose -- this one from a githubs action VM that demonstrated the same behaviour (but which was a clean install of our app). But I think I'll try to fix some of the obvious-fixable issues there. We don't have UF_IMMUTABLE set on anything, and the one process in the suite that uses ESF doesn't protect anything in /Library/SystemExtensions. That process needs the TCC, but without MDM, it requires manual intervention by the user. I don't think it does it on the github actions tests. Each build gets a new number; for annoying reasons, the build is done twice (Apple Silicon and Intel), lipo'd together, and then codesigned again. The crashes you note are either segfaults or reference count crashes, and should not happen -- it seems to be an issue with XPC. The code in question is written in ObjC.