codesign

I’m not sure why you’re having problems with this. Lemme walk you through how I tested this today. You can review my steps to see if there’s anything obviously different. And if there isn’t, you can run through the steps yourself to see if you can repeat my experience. If so, you can then compare your primary daemon to your test daemon to see what’s different. So, here’s what I did: Using Xcode 16.4 on macOS 15.5, I created a new project from the macOS > App template. I set it up as a daemon per the advice in Signing a daemon with a restricted entitlement. Note that the details will differ a bit but the final result will be the same. Specifically, here’s my final structure: % find Test791996.app Test791996.app Test791996.app/Contents Test791996.app/Contents/_CodeSignature Test791996.app/Contents/_CodeSignature/CodeResources Test791996.app/Contents/MacOS Test791996.app/Contents/MacOS/Test791996 Test791996.app/Contents/embedded.provisionprofile Test791996.app/Contents/Info.plist Test791996.app/Contents/PkgIn

[quote='793977021, neil218, /thread/793977, /profile/neil218'] I attempted to codesign my native dynamic library (.dylib) with an entitlement [/quote] That won’t work. Entitlements are only relevant to a main executable. If you sign library code with an entitlement it is, at best, ignored. Creating distribution-signed code for macOS has general guidelines for signing Mac code and it specifically calls this out. Expanding on this a little, when a process runs an executable, the system checks the entitlements claimed by that executable. If all the entitlements are authorised by the executable’s profile [1], the process starts running that program and gains those entitlements. If not, the system kills the process [2]. So, to get this to work you have to change how you sign your app as a whole. This can be tricky. I usually recommend that Java developers start Java by way of a native trampoline. See the info and links in the TCC and Main Executables section of On File System Permissions. However, that tr

[quote='793731021, VarunC, /thread/793731, /profile/VarunC'] If I try to sign my obs app generated in second step codesign --deep [/quote] Don’t use --deep when signing code. See --deep Considered Harmful for an explanation as to why that’s bad. I can’t really help you with third-party tools like CMake. However, we have solid documentation that explains how to sign and package Mac code outstide of Xcode, namely: Creating distribution-signed code for macOS Packaging Mac software for distribution I recommend that you read that, apply the steps manually, verify that things are working, and then research how to integrate equivalent steps into yoru third-party tools. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The recipe to transfer the Developer ID Certs --> MyCertificates isn't perfect....it did allow me to copy the Certs into login / MyCertificates, but if I then try to delete the Developer ID Certs associated with System / Certificates, the delete command deletes BOTH copies of the Cert, leaving me with nothing. The good news is that codesign accepts the Certs I transferred by .p12 file Export / Import onto my M2 computer (which was the higher-level problem). It only gives a warning about finding multiple copies of the same cert. I chose NOT to accept the answer because it leaves the codesign with this warning.

Hi Quinn, Thanks for the information! I tried the link you mentioned, but no luck so far. I tried the following so far: Add com.apple.security.cs.allow-unsigned-executable-memory to the entitlements.plist file. Normalise the Entitlements Property List Re-codesign the .app folder. Notarize and staple the .app folder I tried syspolicy_check distribution my_app.app and got the following App passed all pre-distribution checks and is ready for distribution. But when I try to run the app from the terminal, I still got zsh: trace trap ./path_to_my_app error. When I tried to launch the app by double clicking the .app file, it would exist immediately without launching it.

Below are the Info.plist, entitlements, and App Store profiles for our driver and client app. So, as a quick side comment, when looking into an issue like this, it's critical to look at the actual Info.plist file, not just the Xcode project settings. I happened to have been sent your DEXT by one of our evangelists, but without the actual data, I probably wouldn't have thought of this. In any case, here is the CFBundleVersion of your development DEXT: CFBundleVersion = 1 And here is your TestFlight version: CFBundleVersion = 3433099.287482533 You can read the full details here, but that second version simply will not work in a DEXT/KEXT. I suspect that's the problem here, but covering a few odds and ends: Our driver’s Info.plist specifies both idVendor and idProduct, but our entitlements and provisioning profiles currently include only the idVendor. Do we need to request approval or entitlement inclusion for the idProduct as well? No. There are actually two mechanisms at work here that operate independently. Y

When I initially obtained my Developer ID Application and Developer ID Installer Certificates, they were put in the Certificates under the System Keychain. I don't remember choosing this storage location. The associated private keys were stored in Keys / login. And since codesign was happy with finding my credentials stored this way, but you're saying to Export them they needed to go in MyCertificates, this raises the 2 questions: How do I move my Developer ID Certificates into MyCertificates? How was it decided to install them in the wrong place?

I’m glad you got this sorted. I can’t help you with jpackage, but the general suggestions in Creating distribution-signed code for macOS still apply: Use security find-identity to locate the correct code signing identity. See the doc for the exact command. Note down the SHA-1 hash of that identity. When you go to sign code, pass that SHA-1 hash to codesign. That uniquely identifies the identity, so there’s no ambiguity. I’m not sure if jpackage supports this SHA-1 mechanism but, if not, I encourage you to file an enhancement request against it for that support. It really helps with automated workflows like this. Indeed, if you look at how Xcode invokes codesign [1], you’ll see it that it uses the SHA-1 hash exclusively. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I have an example of that in Command [something] failed with a nonzero exit code.

It looks like you started a couple of new threads for these issues: Keychain Access won't let me Export to a .p12 file Codesign --force not signing 3rd Pty binaries Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com