In response to my feedback submission, apple says that our transparent network proxy is stopping because, somehow, the file descriptor for com.apple.flow-divert is being closed. Only, they haven't (yet?) given any advice on how to debug that -- the extension is written in Swift, and by itself does not close any file descriptor. So I have no idea how I'd go about trying to debug that, let alone fix it. Anyone have any thoughts about this?

This has happened a few times, including out in the field; it's happened on macOS 14 and 15 I think. "This" is: our app runs, activates the extension, it has to get user approval, and... the system dialogue window never appears. The extension stays waiting for user approval. I've got sysdiagnose from one of the systems, and I see the system log about it going into the user approval needed state, and... nothing else. It's there in Settings, and can be approved then. Has anyone run into this? Ever?

I spent 20 minutes trying to figure out why codesigning was failing -- I had the pf block set up correctly, my keychains were unlocked, and then, eventually, it occurred to me, hey, maybe an IP address changed, so I disabled IPv6 except for link local, and then amazingly, it went back to working. I filed FB13706261 over a year ago. This is ridiculous.

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.

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

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 must be missing something obvious here: I've got my packet filter running (yay), but every UDP packet it gets has a destination port of 0. Also I am confused by this other behaviour:             let udpHeader = (bytes + etherHeaderSize + ip4HeaderSize).bindMemory(to: udphdr.self, capacity: udpHeaderSize)             switch Int(udpHeader.pointee.uh_dport).bigEndian {             case 80, 443:                 return true             case 0:                 os_log(.debug, log: Self.log, "UDP port 0: ip_dst = %{public}s", ReadableIPAddr(ipPacket.pointee.ip_dst))                 return false             default:                 os_log(.debug, log: Self.log, "Got UDP packet dest port %#x, ip_dst = %{public}s", Int(udpHeader.pointee.uh_dport).bigEndian, ReadableIPAddr(ipPacket.pointee.ip_dst))               return false             } The case 0 is not used, even though the default prints out a value of 0.

Is there a way to get a notification of some type when a new application is installed? The specifics here have to do with "Here is a list of applications we want to monitor"; I use mdquery to find them (so I can get the paths, and information from the bundle). However, if it's not installed yet, then I can't do that. But if it gets installed later, I'd like to.

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

When doing UDP communications, the socket can either be connected, or not. If it's not connected, it can use sendto to send it to a different destination, and it can use recvfrom to receive from anywhere. (I honestly don't know how often this is used.) An NEAppProxyUDPFlow does not, as far as I can tell, have any way to tell if it has been connected. In fact, the API involved involves an array of datagrams tied to an array of endpoints. But if the provider and the app do not have the same connected state, the results could be not at all what the app expects. Is that correct? Or is it to be expected that it will only expect to get data from the set of destinations, and only that set?

In some cases, one of our daemons will end up with thousands of threads. Clearly a bug somewhere, but I can't see it in the code. (Admittedly, it's C++ which is a bit alien to me still. Anyway.) If I wanted to just be notified each time a thread was created in the process, what are some ways to do that? I assume dtrace and lldb have ways to od it, but I'm not quite sure what.

As I mentioned elsewhere, I am trying to add a packet filter to our app. I can load load the extension, but I am getting permission denied when I try to save the preferences with it. I am building for release, using a Developer ID Application certificate (macOS, if that wasn't clear). I am starting to worry that I can't do this except on an MDM-managed system.

Two different crash patterns -- one an abort, the other complaining about a lock being corrupt or owning thread having exited. The first one is: Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos.overcommit 0 libsystem_platform.dylib 0x18fc10244 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0x18fc0b788 _os_unfair_lock_lock_slow + 332 2 libobjc.A.dylib 0x18f820c90 objc_sync_enter + 20 3 com.kithrup.TPProvider 0x100d2eee0 closure #3 in TPProvider.startProxy(options:completionHandler:) + 340 4 com.kithrup.TPProvider 0x100d2d980 thunk for @escaping @callee_guaranteed () -> () + 28 5 libdispatch.dylib 0x18fa31910 _dispatch_client_callout + 20 6 libdispatch.dylib 0x18fa34dc8 _dispatch_continuation_pop + 600 7 libdispatch.dylib 0x18fa48be4 _dispatch_source_latch_and_call + 420 8 libdispatch.dylib 0x18fa477b4 _dispatch_source_invoke + 832 9 libdispatch.dylib 0x18fa431f4 _dispatch_root_queue_drain + 392 10 libdispatch.dylib 0x18fa43a04 _dispatch_worker_thread2 + 156 11 libsystem_pthread.dylib 0x18fbdb0d8 _pthread_wqthread + 228 12 libsystem_pthread.dylib 0x18fbd9e30 start_wqthread + 8 while the other one is: Application Specific Information: BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt, or owner thread exited without unlocking Abort Cause 198194 Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos.overcommit 0 libsystem_platform.dylib 0x18fc10220 _os_unfair_lock_corruption_abort + 52 1 libsystem_platform.dylib 0x18fc0b788 _os_unfair_lock_lock_slow + 332 2 libobjc.A.dylib 0x18f820c90 objc_sync_enter + 20 3 com.kithrup.TPProvider 0x104e86ee0 closure #3 in TPProvider.startProxy(options:completionHandler:) +340 4 com.kithrup.TPProvider 0x104e85980 thunk for @escaping @callee_guaranteed () -> () + 28 5 libdispatch.dylib 0x18fa31910 _dispatch_client_callout + 20 6 libdispatch.dylib 0x18fa34dc8 _dispatch_continuation_pop + 600 7 libdispatch.dylib 0x18fa48be4 _dispatch_source_latch_and_call + 420 8 libdispatch.dylib 0x18fa477b4 _dispatch_source_invoke + 832 9 libdispatch.dylib 0x18fa431f4 _dispatch_root_queue_drain + 392 10 libdispatch.dylib 0x18fa43a04 _dispatch_worker_thread2 + 156 11 libsystem_pthread.dylib 0x18fbdb0d8 _pthread_wqthread + 228 12 libsystem_pthread.dylib 0x18fbd9e30 start_wqthread + 8 Our TPProvider, whenever it uses a dispatch queue, uses a custom one, so these are presumably system queues and locks. My best guess would be some XPC command took too long? But that's just WAG. Any ideas about what is actually going on?

Multiple times a day, every time I open a new window for forums.developer.apple.com, if I'm signed in, it asks me if I want to opt in to notifications. Even if I click on the opt in button. I've just reproduced it five times in a row here. What is going on?

Clearly not percentage, but the units don't seem to be specified... The real problem we have right now is that, with macOS 15.5, our suite gets a huge amount of "energy impact" points, even though diving into it, it doesn't seem to do that. The most telling example I have of that is: I ran each of our daemons from Terminal, unplugged my laptop, closed the lid, and let it stay there for 8 or 9 hours. When I woke it back up, Activity Monitor claimed it had 2,000 units or so, but after opening all of the disclosure triangles, none of the processes (including the hand-started daemons) used anything close to that. Also, the battery had almost no drain on it. We're getting complaints about this, so I'm trying to figure out what, exactly is going on, but I never looked at the power stuff internally so I don't know how to read the diagnostic files.