Ha ha! Figured it out. Someone set the stderr and stdout in the plist to be a file in /tmp; the first time it's run, it gets created. With a mode of 0644. This was causing it to not launch. (I figured this out by pre-creating the file and doing a chmod a+rw on it, then loading the agent via the previously-used launchctl commands. And then when I logged in as the second user, there was the agent, doing its agenty things.) Ha ha!

If I were in your shoes I’d probably adjust your open source tooling to not do any signing — disable linker signing using -no_adhoc_codesign — then do a final signing step at the end. The build system is xcodebuild driven by cmake; the only code signing is done at the end, and is done by xcodebuild (for each target of the project, which is a system extension, three app-structured daemons, and the containing app). The problem is that we currently have to do two completely-different builds, one for each architecture, due to the lack of support for universal builds by ... well, anything that isn't Xcode-driven, really. In particular, vcpkg, homebrew, and macports all fail at this in various ways. (And we can't use CocoaPods with cmake, and we can't use Swift Packages.)

Hm. I am also not sure if I notarized it afterwards.

The Apple Silicon and Intel builds are currently signed correctly -- they run on Macs of the appropriate architecture with SIPS enabled. (The various libraries are statically linked, not dynamic.) But when I try to use lipo to combine them, it worked on my machine -- until I realized that it had SIPS disabled; when I re-enabled it, I start getting error 8. (Remember how I have now begged Apple for a code sign diagnostics tool? 😄) (Does it matter that it's a single bundle with some contained app / extension bundles, and/or that they have entitlements?)

AH HA! M'ACCUSE! Don't use modal. Then         self.passwordWindow.level = NSFloatingWindowLevel;         self.passwordWindow.hidesOnDeactivate = NO;         self.passwordWindow.floatingPanel = YES; did in fact work.

My code is currently:     if (self.pvc == nil) {         self.pvc = [storyboard instantiateControllerWithIdentifier:@"passwordViewController"];     }     if (self.passwordWindow == nil) {         self.pvc.errorLabel.stringValue = @"";         self.passwordWindow = [NSPanel windowWithContentViewController:self.pvc];     }     self.pvc.passwordDelegate = (id<PasswordDelegate>)self;     self.passwordWindow.title = @"Unlock Password";     self.passwordWindow.level = NSFloatingWindowLevel;     self.passwordWindow.canHide = NO;     self.passwordWindow.hidesOnDeactivate = NO;     self.passwordWindow.floatingPanel = YES;     [self.passwordWindow orderWindow:NSWindowAbove relativeTo:0];     [self.passwordWindow makeKeyWindow];     [self.passwordWindow orderFrontRegardless];     self.passwordWindow.collectionBehavior = (                                               NSWindowCollectionBehaviorCanJoinAllSpaces |                                               NSWindowCollectionBehaviorTransient |                                               NSWindowCollectionBehaviorFullScreenAuxiliary                                               );     [self.pvc reset];     NSModalResponse response = [NSApp runModalForWindow:self.passwordWindow]; which is a mishmash of various things I've been trying, and still no luck. 😩

Oh oh oh oh. I think I see my problem, then: Int(nework_byte_order_short).bigEndian may be what's biting me bigly! Oooh. I hadn't realized that the capacity was number of designated types, not byte length. Although now I'm surprised it didn't crash there. 😄 I do like your Swiftian consumption model a lot. However, I do think it's okay for me to stick with pointers in C, given my background. At this point, I think I'm going to stick with the hybrid model (that is, it calls an ObjC class), but I am copying that Swift code and putting it into my Notes.

I rewrote the packet examination code in ObjC, and it works as expected. I still have no idea what's going on with the Swift code -- the fact that case 0: didn't get caught, but the default: case showed it with a value of 0 just doesn't make any sense to me. 😩

bytes is the UnsafeRawPointer the NEFilterPacketProvider handler gets from the system. The values of etherHeaderSize and ip4HeaderSize are the expected 14 and 20, respectively. I feel like I am missing something very obvious here.

So clearly the pointer is wrong. I'm not sure why it's wrong, though. But looking at the packet (bytes + etherHeaderSize), I find the IPv4 header as expected, and then the UDP header as expected.

The specific line is the guard statement, so yeah, I was going to try to break it up. However, I disassembled at one point:          * At +521, %r13 is 0x0.                                                                                                        * Redirector.o[0x8c70] <+512>:  callq  0x8c75                    ; <+517> [inlined] Redirector.flowSets.getter : Swift.Dictionary<Foundation.UUID, FlowData> + 27 at Redirector.swift:651:43                                                                                                           * Redirector.o[0x8c75] <+517>:  movq   (%r14,%rbx), %r13                                                                       * Redirector.o[0x8c79] <+521>:  cmpq   $0x0, 0x10(%r13)                                                                        * Redirector.o[0x8c7e] <+526>:  je     0x8d35                    ; <+709> at Redirector.swift:651:43 So I assume that %r13 has self.flowSets[id] (rather than id). For some reason, however, I didn't disassemble enough to have %r14 and %rbx annotated.

Ok, that's what I thought. 😄 (And what I am doing.)

We use cmake, so it was a bit more difficult -- and CircleCI, so I had to make sure the dsym files got archived. Did that. Re-confirmed it's this code:         guard let flowData = self.flowSets[id] else {             os_log(.error, log: Self.log, "Could not find flow %{public}@", id.uuidString);             completion(RedirectorError.flowNotFound)             return } id is a UUID; self.flowSets is private var flowSets : [UUID : FlowData] = [:] (where FlowData is a simple class wrapping some flow-related information). This particular method is invoked via XPC from a daemon, with a signature of func handleTCPData(_ id: UUID, data: Data?, completion: @escaping (_: Error?) -> Void). The daemon code is in ObjC++, and it checks to ensure that the UUID is non-nil. So I have no idea why it is segfaulting!

Ah! NEFilterDataProvider! As I said, I figured out that it's the level 2 ethernet, not level 1. I get tunnel vision sometimes.

Ah. If it's just struct ether_header {         u_char  ether_dhost[ETHER_ADDR_LEN];         u_char  ether_shost[ETHER_ADDR_LEN];         u_short ether_type; } __packed; then it makes sense.