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.

I am still digesting that, but I was about to upload another sysdiagnose -- this one from a githubs action VM that demonstrated the same behaviour (but which was a clean install of our app). But I think I'll try to fix some of the obvious-fixable issues there. We don't have UF_IMMUTABLE set on anything, and the one process in the suite that uses ESF doesn't protect anything in /Library/SystemExtensions. That process needs the TCC, but without MDM, it requires manual intervention by the user. I don't think it does it on the github actions tests. Each build gets a new number; for annoying reasons, the build is done twice (Apple Silicon and Intel), lipo'd together, and then codesigned again. The crashes you note are either segfaults or reference count crashes, and should not happen -- it seems to be an issue with XPC. The code in question is written in ObjC.

My Friend the System Log was not at all useful: 2025-06-18 12:43:44.553820+0000 0x6de3 Default 0x0 5681 0 dsa: System extension request com.kithrup.dsa.Extension (0x60000176c8a0) failed with error The operation couldn't be completed. (OSSystemExtensionErrorDomain error 1.) 2025-06-18 12:43:44.554109+0000 0x6de3 Error 0x0 5681 0 dsa: [com.kithrup:ExtensionLoader] Request to load extension com.kithrup.dsa.Extension failed with unknown error, trying again 2025-06-18 12:43:44.554480+0000 0x6de3 Default 0x0 5681 0 dsa: System extension request com.kithrup.dsa.Extension (0x60000176bcf0) failed with error The operation couldn't be completed. (OSSystemExtensionErrorDomain error 1.) 2025-06-18 12:43:44.554635+0000 0x6de3 Error 0x0 5681 0 dsa: [com.kithrup:ExtensionLoader] Request to load/unload extension com.kithrup.dsa.Extension failed with error The operation couldn't be completed. (OSSystemExtensionErrorDomain error 1.) hm, a bit before that, it looks like sysextd crashed, I presume while trying to load it. It, too, is lacking in any useful information. The sysdiagnose has a crash log for sysexted, which is equally helpful: Thread 2 Crashed:: Dispatch queue: sysextd.extension_manager 0 sysextd 0x1013c3a1e 0x101369000 + 371230 1 sysextd 0x1013abc0b 0x101369000 + 273419 2 sysextd 0x1013ab8c6 0x101369000 + 272582 3 sysextd 0x1013af069 0x101369000 + 286825 4 sysextd 0x1013ab680 0x101369000 + 272000 5 sysextd 0x1013ab48c 0x101369000 + 271500 6 sysextd 0x1013ab703 0x101369000 + 272131 7 Foundation 0x7ff8057d7525 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S1__ + 10 8 Foundation 0x7ff805dad25f -[NSXPCConnection _decodeAndInvokeMessageWithEvent:reply:flags:] + 2318 9 Foundation 0x7ff805dae9d8 message_handler_message + 79 10 Foundation 0x7ff805dae4f5 message_handler + 140 11 libxpc.dylib 0x7ff80455f998 _xpc_connection_call_event_handler + 56 12 libxpc.dylib 0x7ff80455e74c _xpc_connection_mach_event + 1399 13 libdispatch.dylib 0x7ff8046760cd _dispatch_client_callout4 + 9 14 libdispatch.dylib 0x7ff8046901a7 _dispatch_mach_msg_invoke + 455 15 libdispatch.dylib 0x7ff80467c088 _dispatch_lane_serial_drain + 393 16 libdispatch.dylib 0x7ff804690cd4 _dispatch_mach_invoke + 484 17 libdispatch.dylib 0x7ff80467c088 _dispatch_lane_serial_drain + 393 18 libdispatch.dylib 0x7ff80467cd39 _dispatch_lane_invoke + 366 19 libdispatch.dylib 0x7ff8046873fc _dispatch_workloop_worker_thread + 765 20 libsystem_pthread.dylib 0x7ff804813c55 _pthread_wqthread + 327 21 libsystem_pthread.dylib 0x7ff804812bbf start_wqthread + 15 (SIGILL aka signal 4, which I vaguely recall is signing related in xnu?)

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.