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.

I checked that periodically, and it never listed a problem. Other people did as well. And now that it's fixed, it doesn't say there was ever a problem.

This appears to be resolved now.

The notarization submitted at 2025-01-15T10:57:41.466Z has completed, but the one at 2025-01-15T11:59:43.559Z hasn't.

Using the history subcommand, I do see the entry for fbcbefe7-39cc-4b18-b31f-ef49397e0af7. The delay started today; one succeeded at createdDate: 2025-01-15T09:01:34.277Z id: 8a48b1d3-cdb3-4e38-a445-5f0518e8b0ba name: foo.pkg status: Accepted which is also today. I am fairly curious about this learning...

Successfully received submission info createdDate: 2025-01-15T10:57:41.466Z id: fbcbefe7-39cc-4b18-b31f-ef49397e0af7 name: foo.pkg status: In Progress

Despite no feedback response, the issue seems to be resolved as of 15.1 or later -- we ran out tests for 55 hours with no insane mbuf leak, and, of course, no panic.

I was very curious why I'd never seen eslogger and it turns out it's because it was introduced more recently than my older systems. 😄 Confirmed that it shows the expected behavior on one machine, so I'll be poking at it. At least I know that it does show SIGKILL actions. Although I guess that's notification, not authorization...

Ok, MAYBE never mind: this may be some weirdness between LS and running under Xcode -- if I run the built app manually, outside of Xcode, then it works on the first attempt. At least on one attempt, anyway; need to poke at it a lot more. Ironically discovered whilst filing a feedback and verifying each of the steps.

No suggestions? I'll go file a feedback, I guess, because it repeatedly ignores the first drag&drop. Second and later, fine.

Which is beyond my (current, at least) capabilities. sigh.