“codesign”

[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

When you get an error like this, codesign usually outputs something helpful to the build report. I explain how to get at that in Command [something] failed with a nonzero exit code. What are you seeing? Sign to Run Locally should be fine in this context, but I generally recommend that you use Apple Development signing. You don’t have to pay to join the Apple Developer Program to use that. Rather, use your existing Apple Account to log in to Xcode > Settings > Accounts and Xcode will set up a Personal Team. IMPORTANT The Personal Team feature has significant limitations. For the details, see Developer > Support > Choosing a Membership. However, those limits are primarily relevant to iOS. Mac developers generally don’t even notice (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com