I found some sample code elsewhere, and -- unless I'm missing something, which is quite likely -- it will not work with a CLI tool, because it needs to know the bundle name.

I still can't find it. 😩

I clearly missed that!

That's what I was wondering, glad is sounds sane.

Yes, I'm not sure where the thread creation code is. Traditionally, I might use dtrace to look at fork and vfork, would bsdthread_create be sufficient here? I could possibly set a breakpoint & log command in pthread_create? There doesn't seem to be an Instrument for checking when thread creation and exit happens.

Created by us, using the 3rd party libevent library, as well as a few others.

Yes, after a year we got it, and are now distributing and it is AWESOME and there is nothing as fun as debugging an ESF-using process and getting distracted for a few minutes. 😄

Dual-booting isn't largely effective for me -- as I said, I don't have spare machines as I'm used to having, so the ones I have are dedicated to various purposes. However! I found the problem! The problem is... VMware just doesn't care about macOS it seems. Parallels, on the other hand, was able to create a VM for me for both Intel Silicon and Apple Silicon. Which means I'll be buying a license for it and using my Mac Pro harder now. And... now I have a justification for getting a Mac Studio... 😄

My best guess is that launchd is confused about something, and can't map the name to the right port. Unloading the extension and reloading it causes launchd to reset the port, and thus seems to fix it. So simply stopping doesn't do the trick. I've had no responses on my FB. Perhaps filing new ones and referencing mine might help?

As I said: I added code to the containing app to periodically try to communicate with the extension, and if it can't, it then unloads and reloads it. This does fix it -- at the cost of having multiple GUI prompts.

As I said, for various reasons, we're using our own window for it. This seems to match my conclusion that we can't do it, yes? Thanks. 😄

See below, hopefully it's clearer?

Weird, I don't get notifications for comments, only replies. For various reasons, we have our own WKWebView window for authentication. We'd like to be able to support yubikeys et al. However... it doesn't look like that's actually possible? Because the WebAuthN support is only provided to full web browsers (and, on macOS [which is all I care about for now 😄], only for the user's default web browser)? As for what we're seeing, when trying to use a Yubikey, our WKWebView window, which is loaded with a google URL, says that it's not supported.

FYI, I had filed FB12006678 a while back, and just updated it to mention this issue as well.

(Ok, I found librproc.h but that seems ... questionable, so is there a less questionable way?)