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?

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

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.

Nobody has any comments or thoughts about this?

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

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

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.

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

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

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.

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

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?

So... if I do a case sensitive search (without the 'c'), it finds it. Weirdly, even if I ask it to find 'safari'. What the what?

The way the build works -- and this isn't just us, it's standard with vcpkg and cmake building on macos -- is that you tell vcpkg the packages you need, it deals with all of the dependencis, and builds them. You then have CMakeLists.txt files that specify your targets, and what packages they link with (and, in my case, I ensured they were static libraries). You then generate a builder (xcodeproj in this case) using CMake; this causes vcpkg to build everything, and then CMake goes and constructs an xcodeproj bundle that has all of the targets you specified, and has all the libraries/header files you said they need as external dependencies used for linking. Then you build, and this basically runs xcodebuild. The end result is the targets signed the way I told it to sign, put into bundles where applicable. Because vcpkg does not support (yet?) universal binaries, I have to do it twice -- once for arm64, once for x86_64. These are completely separate build environments. So I don't have xcodebuild doing "the final step" -- it's actually building everything except the vcpkg-managed dependencies. And I then have one complete bundle for each architecture. So what I want to do is then take those two bundles, and somehow merge them together. I assume this has to be done manually (well, scriptedly) using lio, and then signed again using codesign. I had (as stated originally) thought I'd just grep for the codesign commands from the xcodebuild output, and use those to re-sign after my script uses lipo to put everything together. (I do apparently need to also grab the processed entitlements files.) If there's a way to get Xcode to do this (and this would be a separate xcodeproj bundle, I'm sure), that'd be great. I couldn't find one, since the inputs would be two different bundles. Does that make my question, problem, and dilemma clearer?