Don't need it, obviously! (Of possible interest, though, I'm only interested in finding out information about our own processes, so I assume there's a way to get a task handle for those, even if it involves setting up some XPC between them.)

So it does help to drag the file to the right icon... (since I was debugging it under Xcode, but had the "real" one in my dock). That seems to do it better, but weirdly, it's not happening the first time I drag a file onto the icon. Also, I have this in the main view: .handlesExternalEvents(preferring: ["my-scheme"], allowing: ["my-scheme"]) // activate existing window if exists .onOpenURL { url in // stuff } and both the .openURL and the app delegate method are being triggered. I think this is probably due to confusion on my part, though.

I get the same behaviour using https://developer.apple.com/forums -- just repeated several times in a row, by logging in in this window, then opening a new window and pasting https://developer.apple.com/forums into the address bar. So that's not it.

I've no idea why it wouldn't. It's Safari. I even (just now) turned off content blockers for this site, and it still does this. How would I figure that out? (I have a couple of ad blockers, TamperMonkey, and 1Password as installed & active extensions.)

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

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

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.

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

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.

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

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

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

This appears to be resolved now.

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.

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.