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?

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.

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

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?

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?

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

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.

This query should find everything with a display name of "Safari." That should include, for example, /Applications/Safari.app. [bigbook:/tmp] sef% mdfind 'kMDItemDisplayName == "Safari"c' /Library/Application Support/Apple/Safari /Library/Apple/System/Library/Assistant/Plugins/Safari.assistantBundle/Contents/MacOS/Safari /Users/Shared/Previously Relocated Items 1/Security/System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/f7b05c91052116c046919f72de2c03a86cabcf3e.asset/AssetData/payloadv2/ecc_data/System/Library/Templates/Data/Applications/Safari.app /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.7.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/sef/Applications/Microsoft Office 2004/Office/Themes/safari /Users/sef/Library/Application Support/SyncService/LastSync Data/Safari And yet, /Applications/Safari.app is in fact missing from there. Why? (This used to work. But then mds was broken on my machine, so I bit the bullet and upgraded to Monterey. Multiple Monterey systems are showing this weird behaviour.)

That's pretty much the question: we've got a tunnel provider, and I think the OS' ability to handle a captive portal situation is better than I could do, so is there a way to find out if we are in one, and if so wait for it to be handled by the user before we start doing things?

I was surprised I could not find such a template in Instruments / xctrace; maybe it's in something else and I couldn't find it? (I am trying to figure out why my throughput got slow. Is it because a mutex is too heavy? Or is there a lot of contention over the lock? How long do the locks tend to be held? Etc.)

On Apple Silicon only. It's a bad dereference, address 0xbeadddaf65d0 which looks fake. What does hardening do differently that might cause that, any ideas?

Our transparent proxy provider sends flows to a daemon which analyzes and then does proxying. Works fine. Except that sometimes it stops working. As far as I can tell, it's due to DNS not working. Queries hang -- we've got some internal ones we log, that have timed out after 20 or 30 seconds. Now, clearly, we're doing something bad (because if we kill the daemon and it restarts, everything goes back to working). Unfortunately, I have forgotten so much I can't figure out how to see where it's broken! Things like dig @8.8.8.8 com. any fail -- I am presuming because it's trying to do a lookup of "8.8.8.8" and that fails, but I could be wrong. Admittedly, that one doesn't time out, it simply says no servers could be reached. Meanwhile, pinging that address works. (And, also, the local DNS host -- the one provided via DHCP and listed in /etc/resolv.conf and ipconfig getstatus -- behaves the same way.) I haven't been able to reproduce this myself, unfortunately. Although I have, somewhat interestingly, had a similar issue, which was clearly due to a Google Home WiFi access point (as resetting it fixed the problem, as does moving to another area of the house such that a different AP in the mesh takes over). On my FreeBSD systems, I'd run tcpdump and truss/ktrace on named, but as I said, I've forgotten so much about how macOS does DNS I'm flailing. Help?

root# malloc_history /tmp/stack-logs.60147.10f5f7000.agent-tests.0EDkOu.index -callTree malloc_history[60193]: [fatal] unable to read input graph: The data couldn’t be read because it isn’t in the correct format. I ran my program as root# env MallocDebugReport=stderr MallocGuardEdges=1 MallocStackLogging=1 MallocStackLoggingNoCompact=1 MallocScribble=1 MallocErrorAbort=1 DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib ./test/agent-test (The program then segfaults, which looks to be due to a memory stomper.)

We have a containing app for our network extension; it's set up as a faceless app and run as a LaunchAgent. It works rather well, we're happy with it. Except sometimes, possibly only on M1's, on reboot, it'll show up twice. Our name in the plist is com.kithrup.appName -- simple enough. On reboot, launchctl list shows two com.kithrup jobs -- and the extra one is application.com.kithrup.appName.3238445.3238450. Anyone have any idea about this?

We got a crash in some code, I had managed to miss this topic entirely somehow. This says: Pointer authentication can also expose latent bugs in existing code. In C++, it’s incorrect to call a virtual method using a declaration that differs from its definition. In practice, such calls typically succeed in arm64, but trigger a pointer authentication failure in arm64e. You might encounter this bug when using OS_OBJECT types like dispatch_queue_t and xpc_connection_t. You can’t pass instances of these types from C++ code to an Objective-C++ function (or vice versa) because they’re defined differently in Objective-C++ to support automatic reference counting (ARC). and, yes, we have both C++ and ObjC++ code, and a class does have a dispatch_queue_t member, and it does get passed around (although I don't think anything other than ObjC++ code touches the member), but... the documentation there says "you can't d this" but has absolutely no information on what you are supposed to do instead. Again, I've managed to miss this completely, and my network searching ability is pretty awful, so I assume I simply couldn't find documentation on it? (And I can't stream video very well where I am right now.)