As I've mentioned multiple times, we've discovered some very annoying failures when using a TPP, including FaceTime, AirDrop, and some VPNs. (Tailscale works fine, weirdly enough.) In doing some experimentation today with FortiNet, I was able to get the TPP to work if I added the FortiNet server (which, in our case, is an amazon VM) to the TPP's excludedNetworks list. While it is not working, the tcpdump I got for the host was: 15:15:35.584029 IP (tos 0x0, ttl 64, id 1976, offset 0, flags [none], proto UDP (17), length 412) 192.168.43.16.55067 > ${hidden}.ipsec-msft: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=2 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)) (t: #2 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0100)(type=auth value=fde9)(type=hash value=sha2-256)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 8f8d83826d246b6fc7a8a6a428c11de8) (vid: len=16 439b59f8ba676c4c7737ae22eab8f582) (vid: len=16 4d1e0e136deafa34c4f3ea9f02ec7285) (vid: len=16 80d0bb3def54565ee84645d4c85ce3ee) (vid: len=16 7d9419a65310ca6f2c179d9215529d56) (vid: len=16 cd60464335df21f87cfdb2fc68b6a448) (vid: len=16 90cb80913ebb696e086381b5ec427b1f) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 b4f01ca951e9da8d0bafbbd34ad3044e) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0100) (vid: len=16 afcad71368a1f1c96b8696fc77570100) E.......@.....+.6.8c......6......oW........................|...d...........X.......(..............Q........................(..............Q.........................J.....XE\W(...E/........m$ko....(.......C.Y..glLw7."........M...m..4......r........=.TV^.FE..\......}...S..o,....R.V.....`FC5.!.|...h..H........>.in.c...B{.....LSB{mF].3{.U.z..........Q.......J..N.... .&.............Eqh.p-..t...........h...k...wW.. 15:15:35.901666 IP (tos 0x0, ttl 46, id 23154, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->d1ec3b9d2f311bf5: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 afcad71368a1f1c96b8696fc77570100) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0204) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 8299031757a36082c6a621de00000000) (vid: len=16 9b15e65a871aff342666623ba5022e60) (vid: len=16 ca4a4cbb12eab6c58c57067c2e653786) E...Zr......6.8c..+.......Z>.....oW.......;./1.................<...........0.......(..............Q.........................J.....XE\W(...E/........h...k...wW...... .&.............Eqh.p-..t.......LSB{mF].3{.U.z..........W.`...!............Z...4&fb;...`.....JL......W.|.e7. 15:15:35.901756 IP (tos 0x0, ttl 64, id 41586, offset 0, flags [none], proto ICMP (1), length 56) 192.168.43.16 > ${hidden}: ICMP 192.168.43.16 udp port 55067 unreachable, length 36 IP (tos 0x0, ttl 46, id 23154, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [no cksum] [|isakmp_rfc3948] `.....<"..:...E..8.r..@.}q..+.6.8c...Q....E...Zr......6.8c..+......... 15:15:38.904628 IP (tos 0x0, ttl 46, id 23155, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->d1ec3b9d2f311bf5: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 afcad71368a1f1c96b8696fc77570100) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0204) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 8299031757a36082c6a621de00000000) (vid: len=16 9b15e65a871aff342666623ba5022e60) (vid: len=16 ca4a4cbb12eab6c58c57067c2e653786) E...Zs......6.8c..+.......Z>.....oW.......;./1.................<...........0.......(..............Q.........................J.....XE\W(...E/........h...k...wW...... .&.............Eqh.p-..t.......LSB{mF].3{.U.z..........W.`...!............Z...4&fb;...`.....JL......W.|.e7. 15:15:38.904763 IP (tos 0x0, ttl 64, id 8956, offset 0, flags [none], proto ICMP (1), length 56) 192.168.43.16 > ${hidden}: ICMP 192.168.43.16 udp port 55067 unreachable, length 36 IP (tos 0x0, ttl 46, id 23155, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [no cksum] [|isakmp_rfc3948] `.....<"..:...E..8"...@.....+.6.8c...Q....E...Zs......6.8c..+......... So, given that, I tried adding let msftIPSecHost = NWHostEndpoint(hostname: "", port: "4500") let msftIPSecRule = NENetworkRule(destinationNetwork: msftIPSecHost, prefix: 0, protocol: .any) settings.excludedNetworkRules = [msftIPSecRule] and... it worked. At least, the fortinet client worked, and AirDrop transmission worked. Note that I never saw the flows for port 4500 in handleNewUDPFlow(:initialRemoteEndpoint:) -- just having a UDP rule that would intercept them seems to have caused it to fail. Anyone encountered this, or have an explanation? (I am now trying it in our actual product to see how it works.)

I was trying to check the documentation for handleNewUDPFlow over at https://developer.apple.com/documentation/networkextension/neappproxyprovider/3192017-handlenewudpflow and... it says it's deprecated on everything. Retroactively.

That's pretty much it -- I can increase memory, file descriptor, etc., but can I increase the number of threads? (I've got a case where, in an error condition, my threads block [still trying to figure out why] and new ones are still being generated, until I hit a limit of 512 threads.)

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/c++/v1/__format/formatter_floating_point.h:66:30: error: 'to_chars' is unavailable: introduced in macOS 13.3 66 | to_chars_result __r = std::to_chars(__first, __last, __value, __fmt); Which, ok, I can accept that this is true. Except that this worked on Friday, on the same machine running Sonoma and the previous version of Xcode. The project is configured for a deployment target of 12.0, so it should have failed before, but didn't. (This is a CMake-generated xcodeproj, but that also should not have been any change.)

I'm playing around with using an app to automate some of my personal work flows, and one of the things I wanted to do was to be able to drag a .webloc file onto my app icon in the dock, to launch it. I've got public.data set up as a document type for it in Xcode, which translated to &lt;key&gt;CFBundleDocumentTypes&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;CFBundleTypeRole&lt;/key&gt; &lt;string&gt;Viewer&lt;/string&gt; &lt;key&gt;LSHandlerRank&lt;/key&gt; &lt;string&gt;Default&lt;/string&gt; &lt;key&gt;LSItemContentTypes&lt;/key&gt; &lt;array&gt; &lt;string&gt;public.data&lt;/string&gt; &lt;/array&gt; &lt;/dict&gt; &lt;/array&gt; in the Info.plist for it, which seems correct. When I drag a .webloc file onto the Dock icon, it appears to be willing to accept it, but nothing seems to happen. In the app, I've got an AppDelegate.swift file which has extension Notification.Name { static let receivedURLsNotification = Notification.Name("ReceivedURLsNotification") } class AppDelegate: NSObject, NSApplicationDelegate { func application(_ application: NSApplication, open urls: [URL]) { guard !urls.isEmpty else { return } NotificationCenter.default.post(name: .receivedURLsNotification, object: nil, userInfo: ["URLs": urls]) } } (I copied it almost verbatim from a Medium post.) In the app swift file, I have @main struct LoggerApp: App, DropDelegate { @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate I set a breakpoint on application(_:NSApplication, open:[URL]), and did my drag, and the breakpoint never triggered. I added the application(didFinishLaunching(_:Notification) method, and that does get invoked when the app launches, so the app delegate does seem to be working. That seems to indicate the problem is somewhere else?

I added ES_EVENT_TYPE_AUTH_SIGNAL to the event list, and added logging: os_log_debug(esfLogger, "antitampering signal %d from process %{public}s to process %{public}s", esm.signal, signing.UTF8String, targetSigning.UTF8String); I get some logs, such as 2024-12-09 10:21:47.668034+0000 0xc2c562 Debug 0x0 29448 0 DopeMonitorService: [security.dope:anti-tamper] antitampering signal 0 from process com.apple.spindump to process com.apple.mds_stores But when I do sudo kill -9 ${ourappprocess}, the proess dies with no log generated. (This is a different process than the one using ESF; the goal is, obviously, to keep our processes from being killed, but I'm only at the logging stage so far.) sudo kill -INFO ${ourappprocess} works: 2024-12-09 10:21:38.410851+0000 0xc2c562 Debug 0x0 29448 0 Monitor: [debug:anti-tamper] antitampering signal 29 from process com.apple.csh to process Worker So it is getting through to the monitoring process. But kill -9 ... isn't. Am I missing something obvious again?

% mkdir /tmp/test % cd /tmp/test % touch {a,b,c}{1,2,3,4,5,6}.txt % lf a1.txt a3.txt a5.txt b1.txt b3.txt b5.txt c1.txt c3.txt c5.txt a2.txt a4.txt a6.txt b2.txt b4.txt b6.txt c2.txt c4.txt c6.txt % echo [b-z]*.txt a1.txt a2.txt a3.txt a4.txt a5.txt a6.txt b1.txt b2.txt b3.txt b4.txt b5.txt b6.txt c1.txt c2.txt c3.txt c4.txt c5.txt c6.txt I filed FB16715590 about this. I have a vague memory this might be related to some code to pretend to be case insensitive, but I can't find it now.

I filed FB19631435 about this just now. Basically: starting with 15.6, we've had reports (internally and outternally) that after some period of time, networking fails so badly that it can't even acquire a DHCP lease, and the system needs to be rebooted to fix this. The systems in question all have at least 2 VPN applications installed; ours is a transparent proxy provider, and the affected system also had Crowdstrike's Falcon installed. A customer system reported seemingly identical failures on their systems; they don't have Crowdstrike, but they do have Cyberhaven's. Has anyone else seen somethng like this? Since it seems to involve three different networking extensions, I'm assuming it's due to an interaction between them, not a bug in any individual one. But what do I know? 😄

We're trying out using a 3rd party java applet as part of our suite, but we're getting inconsistent results that seem to be related to signing. "Fortunately," I can trivially reproduce it! It pops up a dialogue saying "Apple could not verify “java” is free of malware that may harm your Mac or compromise your privacy"; if I click through the dialogue and the system settings, it then does the same for each of the dylib files. The file seems to be signed, so is this a matter of it not being notarized? Will we have to sign and notarize them all on our own?

I must be missing something really obvious, and I feel particularly dumb about it: I don't see any event -- authorization or notification -- for creating or removing a directory. I also don't see one for creating a symlink (although that can be handled via unlink, one presumes). The events for create seem to be file only (and I'm also quite surprised that the file mode isn't available in the authorization event for that). So how blind am I here? I mean, I *must* have missed something, right?

Has anyone made a Swift class for IP packets? This is just me being lazy -- the goal is to be able to print them out nicely, and possibly change the values, mainly for experimentation and fun. (I mean, I can do it in C, so I can always wrap that in ObjC and bridge to Swift.)

I wrote a very dumb transparent proxy. The extension simply sends data to a daemon, and that daemon sends network data back to the proxy. It worked with small test connections, and I was fairly pleased. Then I tried transferring a ~4mbyte file (using curl), and it got a way in, and then the daemon did a network read of something like 400kbytes, and went to send that to the extension, and the flow.write method never called the completion handler. If I limit the read size to 64k max, it works. The most frustrating thing is I don't see any logging information related to it, so I can only guess what's going on. Any ideas, thoughts, or clear stupidities on my part?

In particular, network extensions, which need to be installed/activated by the containing app. I'm not particularly great at GUI stuff, so maybe there's a way one can simulate/automate that part? I'm assuming CI testing, presumably done with VMs being created on the fly to build & test. (I admit a historical failure on unit testing for my code, but most of that has historically been kernel code. I'm trying to do better!) I again apologise for my obvious ignorance at some of this.

This is for a non-GUI program -- intended to be a LaunchDaemon at some point; I followed Quinn's instructions for this. As I've commented before, I'm using cmake to generate an xcodeproj (wheeeee), so I wouldn't be surprised if it's doing something wrong. I get the error if I use open Debug/HelperDaemon.app or try to run it in Xcode. That doesn't quite surprise me a lot (again, not a GUI app), and Xcode says there may be a problem with signing. If I run it via the command line (that is, ./Debu/HelperDaemon.app/Contents/MacOS/HelperDaemon), it is immediately killed. I haven't been able to find much in the logs. What I have noted is that if I do codesign --force --deep --sign - ./Debug/HelperDaemon.app, it then does work (although then I run into other crashes). However, doing codesign -vv Debug/HelperDaemon.app, it says everything is fine. (codesign -dv --entitlements :- Debug/HelperDaemon.app shows the entitlements I expect, as well.) This is on macOS; I'm building on and for 11.6, using Xcode 13.1. For the program's entitlements, I've got com.apple.developer.system-extension.install, keychain-access-groups, and com.apple.security.application-groups (although I tried removing that one, with no difference in behaviour).

The NSWorkspace method that does this, fullPathForApplication, is deprecated. So what's the alternative? I do note that oascript can do it by id of app "App Name", so unless that's going away too, there must be some way of doing it, no?