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.

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

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.

I filed FB11522305 about this.

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

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

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

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.

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

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

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

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.

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

Yay thank you Apple! I filed a new request last week or so, making it clear we needed the distributable one, not just the development one, and got the email today, and confirmed that it's there with the development certificate! Yay yay yay!

I thought of that, but I don't think that's going to be it -- the launchd.plist file for it sets the number of file descriptors to a million or so, and there's no messages about descriptors. More worryingly, though, the extension stops getting any network flows. While in this state, I had the engineer do printf foo | nc 127.0.0.1 88, returned immediately with a 0 exit status. And no logs in the extension.