Yip, got the email shortly after I posted that, and am playing with the APIs now. It's neat!

sigh, I forgot that I can't actually do anything until Apple approves my request for the capability. sob

Ha, I didn't mean a kernel-space driver, I was thinking a user-space USB provider of some sort. Thanks for the pointer, I'll take a read soon! Yay!

Ok, the team thing is my fault, as I didn't know about it (and the company was stealth at first, so I was using my personal account for forum & feedback stuff).

I filed the first one, but amn't with Kunal's company now, so (based on other advice we were given) I presume they filed a new issue. But of course I can't see it. 😄

We have tried doing this, to no effect. The Order property seems to be ignored when using MDM. (When we manually installed one extension, waited for it to be activated, and then the other, then flows were processed in that order.) We're using roughly this: <key>TransparentProxy</key> <dict> <key>AuthenticationMethod</key> <string>Password</string> <key>ProviderBundleIdentifier</key> <string>com.kithrup.Multiple-TPP.TPP-2</string> <key>ProviderDesignatedRequirement</key> <string>stuff</string> <key>Order</key> <integer>1</integer> <key>RemoteAddress</key> <string>localhost</string> </dict> to set that one to be the first. We have another one, different company, that we had Order set to 2. And yet, that one always got flows first, no matter what the Order value was. Are we doing something very wrong? Or is this a bug somewhere?

This is happening increasingly often, and just happened on a automated testing VM. I filed FB20555301

I worked in CoreOS for a while, I'm good with spindump files. 😄 It's almost 8pm here, so i'll look at it tomorrow.

There were .diag files in the sysdiagnose, which showed the crash message. The other one I was looking at, which was closer to 100k, had been alive for 40 seconds, based on top.txt.

there any part/component in your app where you have an unrestricted retry loop (try/fail/try... as fast as you can) involving XPC? Hm, not really. We will retry activating the extension, but that's not us using XPC directly; in another case, we'll try talking with the extension using XPC, and if it times out, we deactivate and reactivate the extension. (But that takes 2-3 minutes before it'll get that far.)

Just woke up, so truncated responses: No, not doing any Mach IPC directly -- everything is done via ObjC XPC objects in the GUI app (and Swift ones in the extension). I did notice something else happening, which is that the attempt to load/store the VPN configuration is failing with "wrong type of configuration" or something like that. This causes our GUI app to exit, in the hope that this might cause it to work the 2nd time around, although that doesn't seem to be the case. (So, basically, the GUI app is running for about 40 seconds, and then dying.)

It is signed with a Developer ID. But, as I said, my coworkers ripped a subset out of a bundle, so that presumably broke all the signing.

Wait, no, I've now been told they grabbed java from AWS, and then stripped out parts of it to make it smaller, and as a result lost the bundle structure.

This happened again, even with my attempts to work around it. I updated the fb, and attached the sysdiagnose that was generated. From looking at the logs, it looks like (to me) that it copied the extension bundle into /Library/SystemExtensions, but then decided that it had been modified? Which doesn't make sense.

This is still happening (or seeming to happen) on macOS 14.1 and 15.3.1, sigh (Oops, forgot to mention: one fun case we seem to have is: if the dialogue does not appear, but the system thinks it has, then it will never show up until the system is rebooted. An invisible dialogue box.)