“codesign”

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,

I ended up trying the last two approaches that I mentioned: Running the CI/CD connector directly from Terminal.app Running the CI/CD connector directly from a local ssh session I figured these last two were the most direct in trying to exercise the listed carve outs in TN3179: Understanding local network privacy | Apple Developer Documentation which states: Command-line tools run from Terminal or over SSH, including any child processes they spawn Between each of these tests I restarted the machine since it seems that that's the only reliable way to reset the state for this mechanism on macOS 15.5. Running directly from Terminal.app Here is an annotated screenshot from running directly from Terminal.app Here is a description of each numbered point of interest in this screenshot: You can see that i'm simply directly executing the script from https://github.com/actions/runner/blob/main/src/Misc/layoutroot/run.sh to run the CI/CD connector. I'm ssh'd into the CI machine from a different machine to show the proces

Here are some interesting things I've tried that have made some progress, but don't fully work. Failed Approaches AppleScript Dialog Clicker I created an AppleScript that just runs continuously in the background when a CI job starts looking for these dialogs and tries to dismiss them. It works in local testing, but not when executing through the CI process. I assume this is because it's not being run from a terminal or over SSH and that creates some kind of execution context difference which blocks the clicker from actually working when running in CI. I've tried running this as a simple shell script osascript /path/to/clicker.scpt & and through launchd with launchctl asuser $(id -u) /path/to/clicker.scpt &. I also tried using the launchctl version without putting the script in the background, but that didn't seem to work either. Run GitHub LaunchAgent as a LaunchDaemon The obvious issue is that the current LaunchAgent setup has with respect to Network Privacy is that it's not running as a LaunchDaemon

Hmmmm, this is working for me. Here’s what I did: Using Xcode 26.0 beta on macOS 15.5, I created a new project from the iOS > App template. In Signing & Capabilities, I added Wi-Fi Aware. And enabled the Publish option. I selected Any iOS Device as my run destination. And then built the app. This is what I see: % codesign -d --entitlements - Test788807.app Executable=/Users/quinn/Library/Developer/Xcode/DerivedData/Test788807-dcmkbvkgvfliviecoruqexidkqbe/Build/Products/Debug-iphoneos/Test788807.app/Test788807 [Dict] [Key] application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.Test788807 [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] com.apple.developer.wifi-aware [Value] [Array] [String] Publish [Key] get-task-allow [Value] [Bool] true % security cms -D -i Test788807.app/embedded.mobileprovision | plutil -p - { … Entitlements => { application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test788807 com.apple.developer.team-ide

Additional Update on Developer ID Signing Issue (errSecInternalComponent) Since my previous update, I've taken the following steps: Fully reset the default login keychain and metadata on the affected macOS build machine, resulting in a completely clean, empty login keychain. Imported the Developer ID Application certificate and private key (Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)) from the previous backup into the new login keychain. Verified trust settings and access control for the imported certificate and private key: Certificate shows fully trusted and valid. Private key access control explicitly allows use by codesign. Successfully exported the certificate and private key from the new login keychain without issues, confirming no export-related problems remain. Ran the simplest possible signing test from Terminal: cp /usr/bin/true MyTrue codesign --force --timestamp --options runtime --sign Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ) ./MyTrue This re