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

Of course, that doesn't change the fact that codesign has no useful diagnostics, and does a horrible job of cleaning up after itself.... 😄

meh, it happens. But it doesn't bode well for me -- since that likely means nobody else has run into the problem. siiiiiiiiiiiiiiiiiiigh

This is the line I was adding to /etc/pf.conf on every reboot: block drop from any to 2620:149:981:603::10 ETA: I want to be clear that the ridiculous part is that it's been going on for over a year, that I never got any response even after I mentioned in at least one forum comment that it was still occurring here, and that codesign after decades continues to give no error messages on failure. Oh, also that it doesn't clean up the .cstemp files it leaves behind, which admittedly were the only clue I had what was going on.