The documentation for, eg NEAppProxyProvider, has a lot of redirections and implicit configurations that I simply don't know and sometimes can't follow. I wanted to try making a VPN network extension that (for the moment) just got loaded and did nothing. I can't even get that far, it seems. I'm clearly missing the setup I need to do. Unfortunately, the old SimpleTunnelCustomizedNetworkingUsingtheNetworkExtensionFramework sample doesn't build anymore, what with it being Swift 3 based. Is there a newer, made-for-idiots sample program somewhere?

Has anyone made a Swift class for IP packets? This is just me being lazy -- the goal is to be able to print them out nicely, and possibly change the values, mainly for experimentation and fun. (I mean, I can do it in C, so I can always wrap that in ObjC and bridge to Swift.)

This is mainly caused by my having misread the documentation, but then the behaviour seemed to match my misreading, but then suddenly it didn't. Specifically, I had thought that handleNewFlow could return false to indicate "I'm not interested in this particular connection," but it turns out to close it (killing some but not all? networking on the system) if I always return false. The specific thing I was trying to do was exclude certain apps from being proxied (without building a list of all apps, to filter them all). So my question is two-fold: how dumb was I to misread the documentation, and is there a way to do what I was trying to do? (Short of, say, monitoring all new processes as they start, adding them to the NEAppRule set, and deliberately excluding the ones I wanted to whitelist.)

The proxy doesn't seem to have a way to tell if the application is trying to make an IPv4 or an IPv6 connection (unless the remote endpoint is an explicit IPv4 or IPv6 address). Am I missing something there, or is that in fact how it's intended to be?

I've been trying and googling and forum-reading this for a couple of days, and ... am either missing something obvious, or am simply dumb. I'd prefer to simply be ignorant, and so I ask. 😄 I've got a personal, paid account. I've got some projects, and I've got some git repos. I'd like to allow some other people to check out a repo and then build the associated project. Only they can't, because the bundle identifier conflicts. The bundle identifier is, e.g., com.kithrup.filterTest. In my Xcode, the selected team is me. And that works, which isn't surprising because I did create it after all. I've tried using App Store Connect to invite someone, and they do show up there. But they can't build either, again due to the bundle identifier conflict. (Also they can't find any provisioning profiles, which makes sense given everything else not working.) This is a remarkably basic question for someone who's been developing on the Mac for... oh my, coming up on 20 years in a month. Of course, I managed to avoid Xcode for much of that time, by simply doing unixy stuff. Help?

I know you can go the other way, but I'm curious if there is a way to start with Xcode and end up with CMakeLists.txt?

My project got more complicated, and I had to integrate in some C++ code. In the process, I ended up with a couple of targets, which had some shared ObjC++ and Swift code. Normally, if it's all the same language, I just put the files in question into each of the targets, and we're all happy. But with having both ObjC++ and Swift, I had to deal with the bridging headers. Which got created as ${PRODUCT_NAME}-Swift.h, which made it very difficult for that file to be included in a .mm file used in multiple targets. I tried googling, and forum-searching, and couldn't quite figure out how to make it generate a single header file. Instead, I added a new target, a static library using the common files. I added a Run Script phase which copied *-Swift.h from the Derived Sources directory to the build directory. Then I added the library as a dependency for each of the other targets, and of course linked with it. This seems to work, even after doing a rm -rf build and building everything again. So... was this the (or at least, a) right way to do this? Are there better practices I should be using? Merci beaucou, je suis tres stupid quelquefois.

I wrote a very dumb transparent proxy. The extension simply sends data to a daemon, and that daemon sends network data back to the proxy. It worked with small test connections, and I was fairly pleased. Then I tried transferring a ~4mbyte file (using curl), and it got a way in, and then the daemon did a network read of something like 400kbytes, and went to send that to the extension, and the flow.write method never called the completion handler. If I limit the read size to 64k max, it works. The most frustrating thing is I don't see any logging information related to it, so I can only guess what's going on. Any ideas, thoughts, or clear stupidities on my part?

In particular, network extensions, which need to be installed/activated by the containing app. I'm not particularly great at GUI stuff, so maybe there's a way one can simulate/automate that part? I'm assuming CI testing, presumably done with VMs being created on the fly to build & test. (I admit a historical failure on unit testing for my code, but most of that has historically been kernel code. I'm trying to do better!) I again apologise for my obvious ignorance at some of this.

This is for a non-GUI program -- intended to be a LaunchDaemon at some point; I followed Quinn's instructions for this. As I've commented before, I'm using cmake to generate an xcodeproj (wheeeee), so I wouldn't be surprised if it's doing something wrong. I get the error if I use open Debug/HelperDaemon.app or try to run it in Xcode. That doesn't quite surprise me a lot (again, not a GUI app), and Xcode says there may be a problem with signing. If I run it via the command line (that is, ./Debu/HelperDaemon.app/Contents/MacOS/HelperDaemon), it is immediately killed. I haven't been able to find much in the logs. What I have noted is that if I do codesign --force --deep --sign - ./Debug/HelperDaemon.app, it then does work (although then I run into other crashes). However, doing codesign -vv Debug/HelperDaemon.app, it says everything is fine. (codesign -dv --entitlements :- Debug/HelperDaemon.app shows the entitlements I expect, as well.) This is on macOS; I'm building on and for 11.6, using Xcode 13.1. For the program's entitlements, I've got com.apple.developer.system-extension.install, keychain-access-groups, and com.apple.security.application-groups (although I tried removing that one, with no difference in behaviour).

NEFlowMetaData has sourceAppSigningIdentifier -- but that doesn't have to be the bundle identifier, correct? So is there a way to go from one to the other? (Ideally bidirectionally -- if I can find a bundle, how would I find the signing identifier?)

I had assumed the answer was "copy or create a plist in /Library/LaunchDaemons," but after poking around here and google a bit, I'm more confused. (Which seems to be a normal thing for me, so I'll hold off deciding I'm stupid for a while.) The options that I seem to see are: Copy/create a plist in /Library/LaunchDaemons Have Foo.app/Contents/Library/LaunchAgents, which will, I presume, run something as long as the app is running? Use SMJobBless to install the daemon. This is the preferred way, and requires an embedded launchd plist, which I presume is what will be installedinto /Library/LaunchDaemons? And "embedded" means "pushed into the binary because MachO is infinitely versatile so we can do this if we want to"? This requires user interaction to get an authorization? And... if the app is distributed via MDM, then that can install the launchd plist file without the app needing to run, just like it can install a system extension without the app needing to run?

A successful installation/activation can either be "yay it's done now!" or "wellllllll you need to reboot first but otherwise it's done yay!" So what determines which of those two happens?

This may be dumb: on an Apple Silicon system, with a system extension that is examining / interfering with some process, one or both of them may be run under Rosetta. So if a helper tool (app, daemon, whatever) tries to get the kSecCodeInfoUnique for an application of a given name... will that be the same one seen by the extension? Or will it depend on whether any part of the triad is running under Rosetta?

We started discussing how we'll deal with captive portals, and I realized I don't know if CNA results in network change events. Does it? (I don't have a captive network here, and lockdown makes it hard to go find one, and making one would be ... quite a bit of work.)