codesign

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

I changed the build products location from the default to project relative. This caused the Command CodeSign failed with a nonzero exit code. When I changed the build products location back to the Derived Data folder (default location for Xcode) the build had no errors. I tried to delete the build products from the new location but it did to matter. I had to use the Xcode default or it broke my project. I am using Xcode26 beta.

Fortunately this crash does not appear related to a code signing issue. Execution of Thread 6 branched to an address which just so happened to reside within the GPU Carveout memory region. The GPU Carveout memory region does not contain executable code, nor do those pages have an associated code signature. Hence the CODESIGNING termination reason. But it is better to think of this crash as a segmentation fault (EXC_BAD_ACCESS / SIGSEGV). Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000006d6f632e74 Exception Codes: 0x0000000000000002, 0x0000006d6f632e74 VM Region Info: 0x6d6f632e74 is in 0x1000000000-0x7000000000; bytes after start: 401300729460 bytes before end: 11016130955 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL reserved VM address space (unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL reserved VM address space (unallocated) UNU