I have a weird issue with our Endpoint Security extension. A couple of the checks we do require calling into Apple frameworks (Security, Disk Arbitration) and these checks can happen early in the boot process. On macOS 13 (and possibly earlier), sometimes these calls get stuck and never return. When this happens, the kernel will kill the extension and this generates a crash log. This adds significant time to the boot, enough that people notice. In every case, the thread where the call into the Apple framework occurred shows that the thread is stuck in mach_msg2_trap(), which I now understand means it's likely waiting on an event or message. Now here's where things get weird. I discovered that if I shunt the check off onto a Thread subclass and put it in a DispatchGroup (perhaps the wrong primitive), then wait() on that group with my own timeout, the thread will get unstuck within a couple hundred milliseconds of the timeout. The timeout can be a couple of seconds or longer. In every case, the thread unblocks, returns from mach_msg2_trap() and the original call finishes as expected. Is there a rational explanation for this behavior? Am I crazy to even consider shipping this workaround?

We are trying to get much more serious about our ability to audit signed code and trace it back to a signing event. We have a signing service that includes a bit of client code that provides a CryptoTokenKit extension to expose the signing certificate to codesign and Xcode. The private keys are held by the signing service and access is strictly controlled. The CTK extension is given a message/digest to sign, and from reading TN 3126, I believe this is representative of the code directory. For an audit trail, we can record some metadata about the signing request, such as Git repository, branch, commit SHA, etc., but the only value linked to the thing being signed is this blob. Later, if we have an app and want to link it back to the signing event, I can't figure out how to find this blob. It's not the CDHash or any other value I see in the output of codesign -d -vvvvvv. is there a way to recreate that blob given a signed artifact?

I'm trying to send various user input events to a virtual machine. The app is built in SwiftUI, so the VZVirtualMachineView is part of a view controller wrapped in NSViewControllerRepresentable. Non-modified keystrokes and mouse clicks work fine, but I can't send modified keystrokes (e.g., ⌘F). These come through without the modifier (e.g., plain F). I also haven't been able to get mouse scroll wheel events to do anything in the VM. I installed a local event monitor with addLocalMonitorForEvents(matching:handler:). Before the VM boots and the VM view exists, typing myself generates events that I see with the monitor. After the VM boots, though, the monitor does not see any of my keystrokes. The monitor never sees any of my programmatically generated events. I am sending these all through NSWindow.sendEvent(_:). Is there anything special about VZVirtualMachineView that might affect how it handles injected events? It's obvious possible (likely) that I'm doing something wrong with how I build and/or send these events into the application. Can anyone point me to documentation or examples that aren't easily found through search engines?

My company uses a VPN to provide access to cloud services for development purposes. I am unable to reach these services from VMs or devices using Internet Sharing. In both cases, those instances can reach the Internet just fine. Here is what the routing table looks like for the VPN: 100.20.x.x 100.65.0.1 UGHS utun1 100.21.x.x 100.65.0.1 UGHS utun1 100.64/10 utun0 Uc utun0 100.65/16 100.65.0.1 UGSc utun1 If I add a custom pf rule, I can get the VM packets routed to the VPN: nat from 192.168.66.0/24 to 100.65.0.0/16 -> (utun1) But, inexplicably, a similar rule for 192.168.2.0/24 does nothing. Using Wireshark, I still see packets sent out the default interface, instead of being sent through utun1. Two questions: Why doesn't the routing "just work" in this case? I expected that, after the NAT rules installed by the system are applied, the packets destined for 100.64.0.0/15 would be properly routed without the need for any custom rules. What else should I try, either to gather more data or attempt to fix the routing?

I'm working on a command line tool that uses the Accessibility APIs on macOS. Running inside Xcode works fine, but directly from the command line I still get false from AXIsProcessTrustedWithOptions, even though the switch in System Settings is turned on. The binary is signed with a Developer ID certificate. What else should I look at to debug?