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

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?

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?

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?

I create a protocol that had, among other things: @objc func setList(_: [MyType], withReply: @escaping (Error?) -> Void) The daemon part is in Swift, while the calling part is in Objective-C. Because why not? (Actually, because the calling part has to deal with C++ code, so that's ObjC++; however, I wanted the stronger typing and runtime checking for the daemon part, so I wrote it in Swift.) The ObjC part uses NSArray<MyType*>. I set up an NSXPCConnection link, and create a (synchronous) proxy with the right protocol name. But when I try to do the XPC setList call, I get an error. I assume that's because it doesn't like the signature. (Surely this is logged somewhere? I couldn't find it, if so. 😩) But... if I have a signature of @objc func addItem(_: MyType, withReply: @escaping (Error?) -> Void), then it works. So I assume it's the array. (Oh, I've also tried it without the @objc; the protocol itself is defined as @objc.) I've tried changing to protocol signature to using NSArray, but same thing.

The NSWorkspace method that does this, fullPathForApplication, is deprecated. So what's the alternative? I do note that oascript can do it by id of app "App Name", so unless that's going away too, there must be some way of doing it, no?

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

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

We're using CMake here, so we can build on Windows, Linux, and macOS. So now I'm trying to convert from Xcode to CMake (which then generates an xcode project, whee). The main problems I'm running into are figuring out which settings to do via CMakeLists.txt. That's mostly tiresome. But theres a new issue, and I don't know enough about CMake to figure it out: compiling my .swift file generates a ${PROJECT}-Swift.h file, which is used by the ObjC files. Which is great. Except I don't know how to tell CMake about that. (And I haven't figured out what variable describes where Xcode puts it, but that's more of a tiresome issue than head-against-desk issue...) Has anyone run into and hopefully figured this out?

As I asked earlier, I was trying to figure out who the current user is. Since the proposed solution doesn't work, I thought, okay, let's try sending notifications from a LaunchAgent! Only, right, notifications are per-process, so I tried Distributed Notifications... and that doesn't seem to work across users. (Now, since I log while also sending the distributed notifications, I can see that it is working the way I want. Except that willPowerOffNotification doesn't actually seem to happen with a logout. Maybe that's because it's a CLI program? But the other notifications do work...)

There's the NSWorkspaceSessionDidBecomeActiveNotification et al, but that doesn't say who the current user is. Is there a way to find out that? (I mean, I could have a LaunchAgent that send "I've become active!" log message or something, and then use the most recent one. Is there another way?)

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.

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?

On three different machines (all running Xcode 13 and Big Sur), it always tells me that the command-line developer tools need to be installed. I've "installed" them four times so far on one machine, and at least twice on the other two.

On three different machines (all running Xcode 13 and Big Sur), it always tells me that the command-line developer tools need to be installed. I've "installed" them four times so far on one machine, and at least twice on the other two.