No, that was simply PEBKAC. It turns out you need to call connection.resume() when making an XPC connection.

One thing I thought to try to do was to have the extension try making an XPC connection to itself, but that doesn't work, presumably due to sandboxing.

A work-around for the users. I managed to get my system into quite the state testing this -- an old version of the extension stuck around, despite multiple reinstallation attempts; kill -9 did absolutely nothing to it; using systemextensionctl to uninstall it did that, but then it couldn't be re-installed. I rebooted and all was well with the system again. Mind you, it's hard to tell how much of those issues were caused by this being a development machine, which means it is sometimes in a very questionable state. 😄

I filed FB11653435, and attached a very simple project to it which demonstrates the issue.

(Also, it reproduces when not run as a launch agent, so that's not the issue. It seems to be that the system will, when one user clicks "Open security prefs", open it on all sessions where the containing app is running. I'll try to make a small test case for a feedback, but that will take a fair amount of time when I don't particularly have a lot right now.)

It is a (faceless, but with menubar icon/menu) GUI app. It just happens to be automatically launched as an agent, both to ensure it's there for everyone, and to keep it running. It isn't automated, more than any other program is, and it's there to interact with (included activating and deactivating) the extension, as is required by Apple's design. And all that is done in a GUI context, which causes user interaction if necessary. (The only weird thing we're doing is, as part of the postinstall script, using launchctl bootstrap to get it running for all currently-logged in users. As is documented.) And none of that answers my question, which was whether or not SysPrefs being launched on a resigned console was expected behaviour or not.

(Sorry, I should clarify: both the user in question, and I, log into the systems in question using screen sharing -- for me, it's in a different room, up some stairs, and I am lazy. I just rebooted it and made sure that if I log in only via screen sharing, it works for me. What we're ignoring is is multiple simultaneous console logins, which I can never remember how to do.)

We are ignoring that for now, although now I am wondering if that's the cause. But... the stand-alone program worked, so I'd ruled that out as a possibility. (Both this person and I generally access our machines via screen sharing, mind you.)

Yes, due to the IPC being used by the other parts of the suite using a broadcast mechanism, instead of point-to-point. Some of the actions, as a result, should only be taken if the current user is on the console. (E.g., trying to load the network extension.)

I filed FB11522305 about this.

And I still can't figure out why it's happening. Or, more importantly, how to stop it. The spurious one can be quit, at least, but I'm not seeing any reason why it would be re-launched on login.

No. At this point, Apple has decided that we are not allowed to compete in certain markets. They're also ignoring our pleas.

Oh, alas, propertiesRequest(forExtensionWithIdentifier:queue:) is only available in macOS 12 and later -- we're still supporting 11. Or I think so, anyway; I'll have to see if we've updated our requirements.

That’s not correct. The container app can get information about an installed sysex using propertiesRequest(forExtensionWithIdentifier:queue:). I thought that only worked for the particular process that loaded it -- but I haven't played with that too much. Additionally, both the sysex and the NE configuration are system-wide things, not per user. If user A installs these and then user B runs the app, it’ll see them. But will both instances of the containing app be able to get the VPN notifications? Or only the process that actually loads it? I thought I ran into that not working, but I think I was doing something very wrong at the time to begin with. Finally, NE sysexes can provide an XPC named endpoint using NEMachServiceName. That’s registered in the global Mach boottrap namespace, so any process on the system can connect to it (modulo sandbox restrictions). Yes, we have multiple processes doing that, and yes, I am going to add a call to get the version from the extension. Thanks 😄

Ok... so I'm still confused why there is a document saying "here's what you need to know about Pointer Authentication," which specifically mentions a couple of types and circumstances. Should I file a feedback request for improving that page? And the crash reports that say "this might be a pointer authentication crash"? 😄