But that gets back to my original question -- can I just grep the codesign commands from the build output, and do those again after the enfattening? Or do I need something different after that?

Yeah, macOS, using Transparent Proxy Provider. I tried using network reachability, but that didn't do it, alas.

Oh: also, if I can do it anywhere in the OS, that's fine -- I can tell the provider to disable itself for a while, easily enough.

I filed a TSI. I suspect that it'll end in an Enhancement Request rather than a solution, alas. I'd love to be wrong. 😄 (And I just filed FB10449617 anyway.)

Ok, so it's been a while: I did get it to work! I grepped the codesign commands from the build output, wrote a script that, given two source .app directories, copies one of them to a new bundle, and then runs codesign on each of the bundles (including, at the end, the whole enclosing bundle). I also (cleverly, I think) extract the entitlements using codesign rather than using the ones from the project directory, and apply those. It seems to work! This is, I think, about the best I can do until and unless uSoft or MacPorts makes progress on their respective tools/environments. This is one of the reasons I always like being an OS engineer, so we don't have to (in general) rely on third party libraries/tools. Now I got a hankering to write a copyfile class in Swift.

I assume we're hitting some resource limit, but... I don't know which one, or how to find out. :(

The TPP looks for specific flow types (using the application and destination), sends them up to the daemon if they're interesting, and then the daemon modifies them if necessary and sends them out to the internet. I'm thinking not just DNS at this point -- that is definitely failing, but I think almost all networking is blocked by something -- I see mdns traffic, but nothing else. And if we restart the TPP, it gets maybe one or two flows, which it then sends off to the daemon, and then nothing else. Whereas if we restart the daemon, everything starts working properly. For a while, before repeating. I haven't been able to reproduce it! But several other people can do so, fairly reliably.

We ran into that early; the launchd.plist file for it sets the open file limits to 1000000.

Well, you can, but it's not really ideal. Of course, you also can't make a product without Apple's permission, and we're at 8 months of "sorry, they'll let you know if they ever make a decision, and there is no escalation," so...

Nobody has any comments or thoughts about this?

I guess I wasn't clear -- I don't want notifications from my app, I want to find out when an application is installed. Or removed, that would be nice too, but less important.

No more kernel drivers, and even after 8 months we still don't have the ability to ship a product using endpoint security.

This is only possible for an admin user. Trying to protect yourself from admin users is kinda pointless IMO But it is there, in that you can't install or remove a system extension even as root. I had actually expected this sort of functionality with MDM at least, but it doesn't seem to be the case unless I missed something?

I filed FB11080821, thanks Quinn :)

It's hard to tell, since it works properly at least 80% of the time... Next times it happens, I'll try getting it to think it's a fresh install.