The extension is a Transparent Proxy Provider, so that's the authorization that should come up. We've had this happen occasionally on our automated tests, which run in a VM with no other extensions installed, so I think I can rule that out. (The automated software expects the window to appear, so it can then "click" it; it doesn't, so the test fails. Intermittently.) I just filed FB17948001, with the sysdiagnose attached. I know it's WWDC so honestly I'm not expecting anyone to have a lot of spare cycles. 😄

I don't remember if we ever met; if not I'm sad now. That was an incredibly useful and helpful amount of information, so while it's going to take me a while to digest, I wanted to point that out first.

Here is an example of what confuses me: the total is 500 units, but each of the windows has 0.0 units.

The extension gets calls for sleep and wake, and log them. Nothing else happens in the interim, other than (sometimes) some already-existing flows. The other daemons opt into IOKit's power notifications, and when sleep happens, they set it up so any timer-invoked actions just return immediately. The GUI app doesn't do anything special for sleep or wakeup, mainly because I wasn't sure what I should do. 😄

That link doesn't work...

Took a while, but this looks like it would do it: AltSecurityIdentities: X509:<T>CN=Apple Root CA,OU=Apple Certification Authority,O=Apple Inc.,C=US<S>CN=com.apple.idms.appleid.prd.001006-08-6e1a760f-f653-4f65-b28d-2d5dd5ff9582 PlatformSSO:foo@kithrup.com So that's the key AltSecurityIdentities, and it looks like that then has a dictionary or array? Now how would I get that programmatically...

Annoyingly, we don't have anything set up internally, and of course I never set up LDAP at home... (I tried once. Too annoying. Anyone got pointers?) I'm also, as of right now, trying to figure out if there's a difference between the account name and an email address.

We might be. The specific thing we're doing is logging in via OIDC, and we can try to check various email addresses before asking the user. I think we only really care if the user is part of a network directory, though.

We made a slight changed to our code -- no need to use the airport command to try to get SSID names, since that's no longer possible -- and macOS 15.4.1 seems to have had its own changes that significantly improved things.

NB: it appears to be a different issue.

For us, it happens on both Apple Silicon and Intel, and only on upgrades. Once this happens, it can only be fixed by uninstalling the extension and re-installing it, which is super annoying because that means that (without MDM) it needs to be approved by the user twice. (Well, ok, a reboot also fixes it. But killing the extension and letting it restart doesn't fix it, is more my point.) Honestly this seems like a bug with launchd.

It does not appear to -- setting LC_ALL to "" and "C" results in the same behaviour. It only happens with ranges; using echo [bc]*.txt works as expected.

Again, it doesn't seem to show past status events for me, but it does report that it's available now. It only took, what, 5 hours for it to update and say there was an outage for everyone? siiiiiiiiiiiiigh But working now! That's good. 😄

90 minutes and counting, and all systems available according to apple. For the -insiders who are curious, id 4c14db6a-ff56-495c-be2c-0c21c3719da0

AH HA! I have found two problems! I had it set to cache the results, which resulted in no more auth messages. I convert the messages to an ObjC class, and for the process initialization, I'd forgotten to initialize the pid property. This resulted in all processes having a pid of 0, which of course I skipped because that's the kernel! (I allow launchd, aka pid 1, to send signals. Things get bothersome otherwise.) PEBKAC FOR THE WIN! 😄 This took a long time to diagnose because it's a bad idea to use breakpoints on a process that is using ESF for authorizations.