Is it better to Create an NSXPCConnection, keep it around, and create proxies using that as needed, or Create an NSXPCConnection, create a proxy off of it, and then close the connection when done?

A bad time to ask, I'm sure, since everyone is busy with WWDC. What is the difference between filterSockets and filterPackets? In terms of code and classes, I mean. (For my very simple test, if I set filterSockets to true, it just doesn't seem to work.) Related to that: with filterPackets set to true, what data is NEFilterPacketProvider.packetHandler getting? It looks like a subset of an ethernet packet on my system (which, in fact, does have wired ethernet!). But it's missing some of the wire bits (the preamble and SFP), and the length is wrong. (Eg., the handler is given bytes of length 1514, but the ethernet length field is 1500 -- but there are 16 bytes before the length field, plus the two bytes of the length/type.) I suppose it's possible it's not an ethernet packet, but it certainly looks like one, just... slightly wrong.

I thought Swift wasn't supposed to get them, which is part of the reason why I chose to use it for my network extension. But we're getting crashes occasionally, that look like: Thread 4 Crashed::  Dispatch queue: com.apple.NSXPCConnection.user.endpoint 0   com.kithrup.MyApp.NExt                  0x102c4ffe2 MyExt.sendData(_:data:completion:) + 610 1   com.kithrup.MyApp.NExt                  0x102c5091f @objc MyExt.sendData(_:data:completion:) + 255 2   Foundation                              0x7ff81ef97490 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S3__ + 10 3   Foundation                              0x7ff81ef3fa1f -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 2322 4   Foundation                              0x7ff81eef641e message_handler + 206 5   libxpc.dylib                            0x7ff81de24b6c _xpc_connection_call_event_handler + 56 6   libxpc.dylib                            0x7ff81de23947 _xpc_connection_mach_event + 1382 7   libdispatch.dylib                       0x7ff81df2e3b1 _dispatch_client_callout4 + 9 8   libdispatch.dylib                       0x7ff81df47041 _dispatch_mach_msg_invoke + 445 9   libdispatch.dylib                       0x7ff81df341cd _dispatch_lane_serial_drain + 342 10  libdispatch.dylib                       0x7ff81df47b77 _dispatch_mach_invoke + 484 11  libdispatch.dylib                       0x7ff81df341cd _dispatch_lane_serial_drain + 342 12  libdispatch.dylib                       0x7ff81df34e30 _dispatch_lane_invoke + 417 13  libdispatch.dylib                       0x7ff81df3eeee _dispatch_workloop_worker_thread + 753 14  libsystem_pthread.dylib                 0x7ff81e0e1fd0 _pthread_wqthread + 326 The XPC method is func sendData(_: UUID, data: Data?, completion: @escaping (_: Error?) -> Void) It's crashing on address 0x10, so pretty clearly a NULL-dereference. Since this is happening in my extension, it's in Swift (as I said above), so I have no idea what could be NULL without the compiler yelling at me first.

Again, none of this is really my choice: our project is multi-platform (specifically, at this time, Windows and macOS). As a result, the people who started 8 hours before I did picked CMake and vcpkg to handle build system generation and 3rd party dependencies. (TBF, I can't blame them for this, since this does work on a Mac, for at least a simple build.) I want to support Apple Silicon, obviously. I can build native on my M1 MBP. (I could, theoretically, use lipo and create a universal bundle, but that would mean manually signing a handful of executables, and then the whole thing, unless I missed a way to do this much more easily?) We're using CircleCI for CI, or maybe github actions in the future. I have not been able to figure out how to use CMake and vcpkg to do a cross build. Not even universal, just "build for arm64 on Intel mac". googling and searching these fora hasn't shown a lot that seems to work (mainly, I think, for the vcpkg side). Which is weird, because one of the things people use CMake for is to build Android and iOS apps, which generally does mean cross-compiling. Does anyone know how to do that? I'm at the point where I'm looking at CocoaPods again -- but that will not work with CMake, so we'll have two completely different build systems, one of which requires a Mac with GUI to add/remove sources/targets.

Our TPP excludes our own processes from oversight, which makes some things very easy. Only I just found out that when our app uses a WKWebView... it's very securely shuffled off into its own process. With its own signing identifier. And a ppid of launchd. How could I tell that a com.apple.WebKit.Networking process is related to our process? (I note that the Endpoint Security Framework has added a "responsible" audit token, presumably for this sort of situation.)

For a variety of reasons, some of which are no doubt due to poor life decisions, I don't want my application to start automatically on restart. Is there a way to exempt myself from that?

I was trying to figure out how to monitor keychain events, and wrote:         dispatch_async(dispatch_get_main_queue(), ^{             OSStatus kr = SecKeychainAddCallback(MyKeychainEventCallback, kSecEveryEventMask, NULL);             printf("Got result %d\n", kr);         });         dispatch_main(); However, the callback never gets called. I put the same code into a simple GUI app (invoked from the didFinishLaunching method), and it does work. So presumably this is something run-loop related. But I can't seem to figure it out -- so what am I doing wrong?

We'd prefer our security application not be worked around by the complex task of typing sudo launchctl unload /Library/LaunchDaemons/foo.plist 😄. Is there a way to prevent that? (We're not using ServiceManagement because we need ot control some of the plist entries, sadly.)

I can use /usr/bin/security to install a root CA, and to delete it (based on the file)... but how do I check to see if it's installed already? Surely there is a way to do this, other than security find-certificate -a | fgrep my.ca.name? Ideally from the shell level, but if I have to write a program I can (in which case I believe it'd be a relatively easy, albeit annoying because I hate writing certificate code, task)...

Is there a way to see which profiles are downloaded (in ~/Library/MobileDevice/ProvisioningProfiles) in a human-readable method using Xcode? Specifically, I'd like to know what type (and for which certificate(s)) each profile is. Looking at them with emacs is ... annoying, even for me. 😄

Despite updating to the most recent Xcode repeatedly, I was never able to add a swift package using Xcode -- it would get stuck at validation and never get past that. I filed a feedback (and may have asked here? can't find it) and never heard back. Today, I managed to figure it out, by creating a project on one machine (where it worked), and checking it out on one that didn't work. And when I tried to launch Xcode on the second machine... it told me that it couldn't use swift packages with a legacy build setting. I changed that (long, long, long set) preference, and... suddenly it worked. In case anyone else is as stubborn and ludditious as I am, and find this useful.

My little network extension is running out of file descriptors. My suspicion is that something in the Security framework is not being deallocated, although even this doesn't make a great deal of sense: The extension looks at each flow, and gets a SecStaticCodeRef for it, finds the pathname, makes a decision, and stores the result of that decision in an NSCache<NSData, NSNumber> where the key is flow.metaData.sourceAppUniqueIdentifier. This goes through a couple layers of abstractions (the cache is in one Swift class, and it calls another Swift class that gets the security info and then returns the pathname, or throws an error). As an example, after running for a couple of days, it has 1074 open file descriptors for /System/Library/PrivateFrameworks/CloudKitDaemon.framework/Support/cloudd -- and only had 732 three hours ago.

This specifically seems to happen when my network extension is spawned by launchd, but has not actually been connected. (That is my conclusion based on the evidence: ps shows the process existing, but the logs show that main() hasn't run yet, let alone the proxy provider's init(). Without being able to debug launchd, I would say the situation is that launchd has said "yes this XPC port exists, when you try to connect to it I will send it on over to the extension, and thereafter you two will happily communicate directly," but the process hasn't gotten around to accepting XPC connections.) This seems to be most likely to happen when the extension crashes, or I kill -9 it to see how it handles respawning. I have a little CLI tool that talks (over XPC, of course) to the extension, mainly to say "Hi are you alive?" If the extension is not loaded, the XPC connection fails, as expected, and my tool says "NOT YET." If it is loaded and running, the XPC connection succeeds, as expected, and I get back a response of true. So my first question is: is this expected behaviour? My second question is: is there a way to do an XPC connection with a timeout?

I mean, I could do a readdir on /Library/SystemExtensions/, but that won't really tell me which ones are active. I could parse the output of systemextensionsctl list but that doesn't seem particularly good.

I've got a preference that requires the app to restart to take effect, so I would like to quit it. Using NSApp.terminate(nil) doesn't do it. Everything I can search for seems to be talking about iOS (and being able to relaunch the app would be good for iOS, if that's a doable thing?).