I filed FB11861011 just now.

I at this time only care about macOS. 😄 How can you stream using OSLog though? (Specifically, during diagnostics generation, I want to grab the log stream --info --debug --predicate 'subsystem == "us"' equivalent for a few seconds.) Using the enumerator seems to give me up to a point in time, but then it ends. There is OSLogEntryActivity but I'm not sure that's the right thing. And I can't find any examples of it.

The reason I was using LIKE is because I couldn't do a case-insensitive query without. I still can't, despite the documenation. For example, it uses kMDItemAuthors ==[c] "Steve" and just below that explains that the [c] means it is case-insensitive. And yet: sef% mdfind 'kMDItemDisplayName == "Safari"' /Applications/Safari.app /Users/Shared/Previously Relocated Items 1/Security/System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/f7b05c91052116c046919f72de2c03a86cabcf3e.asset/AssetData/payloadv2/ecc_data/System/Library/Templates/Data/Applications/Safari.app /Library/Application Support/Apple/Safari /Library/Apple/System/Library/Assistant/Plugins/Safari.assistantBundle/Contents/MacOS/Safari /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.7.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/sef/Library/Application Support/SyncService/LastSync Data/Safari sef% mdfind 'kMDItemDisplayName ==[c] "Safari"' sef%  (Also, I thought that LIKE used the SQL wildcards.)

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.

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!

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.