codesign

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.

I just filed FB17948001, with the sysdiagnose attached. So, I was able to take a look at it today and there are definitely some oddities I don't understand. FYI, the list of things below constructed across a significant period of time, so it isn't order in any particular way nor is it necessarily prioritized. (a) One of your components (ProxyAgent) crashed twice, with a reboot in between. You can find the crash log data in the system log archive by looking for pids 1401 and 339. The crashes themselves are fairly similar, with a high thread ID GCD thread crashing here: 6 0x101581398 -[ExtensionLoader asyncControlProxyWithErrorHandler:] 7 0x10102cebd -[AppBypassCollector sendAppEntry:] 8 0x10157e847 -[AppEntryCollector addName:] 9 0x10102d2a2 AppBypassConfig::sendListByOS(std::__1::set 0x1010226d5 AppBypassConfig::sendAppBypassList() I'm not sure how it connect (if at all), but the timing is suspicious as it lines up with about the time the system extension activation started. (b) An app update is what trig

I did try the approach of moving it into the PlugIns directory and still App store expected me to codesign all the dylibs and the binaries with entitlements. Certainly. Here is an ancient post that may still be relevant for you: https://stackoverflow.com/questions/16960662/embedding-a-java-runtime-into-a-sandboxed-cocoa-mac-app It may be possible to just slap entitlements on the binary. I don't know. Another option could be to integrate the runtime into your executable. And finally, take another look at the license costs for the .NET version and keep that in mind as your burn hours trying to get Java to work.

Thanks @DTS Engineer and @Etresoft But the exact problem here is something else relating to security issues. I did try the approach of moving it into the PlugIns directory and still App store expected me to codesign all the dylibs and the binaries with entitlements. The problem arises when I had to add the com.apple.security.app-sandbox entitlement to the java executable to avoid thie error. ITMS-90296: App sandbox not enabled - The following executables must include the 'com.apple.security.app-sandbox' entitlement with a Boolean value of true in the entitlements property list: [[com.app.sample.appstore.pkg/Payload/Sample.app/Contents/PlugIns/Java.runtime/Contents/custom-jre-universal/bin/java]] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. So when i added an entitlement file and codesigned the java executable inside my PlugIns directory and after which when i run the java executable I get this error,