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

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!

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

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.

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.

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.

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. 😩

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.

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. 😩

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.

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?)

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

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.)

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!

The way the build works -- and this isn't just us, it's standard with vcpkg and cmake building on macos -- is that you tell vcpkg the packages you need, it deals with all of the dependencis, and builds them. You then have CMakeLists.txt files that specify your targets, and what packages they link with (and, in my case, I ensured they were static libraries). You then generate a builder (xcodeproj in this case) using CMake; this causes vcpkg to build everything, and then CMake goes and constructs an xcodeproj bundle that has all of the targets you specified, and has all the libraries/header files you said they need as external dependencies used for linking. Then you build, and this basically runs xcodebuild. The end result is the targets signed the way I told it to sign, put into bundles where applicable. Because vcpkg does not support (yet?) universal binaries, I have to do it twice -- once for arm64, once for x86_64. These are completely separate build environments. So I don't have xcodebuild doing "the final step" -- it's actually building everything except the vcpkg-managed dependencies. And I then have one complete bundle for each architecture. So what I want to do is then take those two bundles, and somehow merge them together. I assume this has to be done manually (well, scriptedly) using lio, and then signed again using codesign. I had (as stated originally) thought I'd just grep for the codesign commands from the xcodebuild output, and use those to re-sign after my script uses lipo to put everything together. (I do apparently need to also grab the processed entitlements files.) If there's a way to get Xcode to do this (and this would be a separate xcodeproj bundle, I'm sure), that'd be great. I couldn't find one, since the inputs would be two different bundles. Does that make my question, problem, and dilemma clearer?