As mentioned in https://developer.apple.com/forums//thread/759955 I was having trouble on macOS 15 with a launch agent accessing local network resources, even if the local network permission dialog pops up, and Settings app visually claims the app has permission granted.
The following was logged:
nehelper +[NEProcessInfo copyUUIDsForExecutable:]_block_invoke: failed to get UUIDs for /Users/foo/my-binary
It turned out that the problem was caused by the default golang toolchain not producing a LC_UUID load command, which seems to be critical for the network privacy subsystem to determine whether the binary is allowed access or not.
The issue has been reported upstream here: https://github.com/golang/go/issues/68678
To work around this I added -ldflags="-linkmode=external" when building the go binary, so that the system linker (which does add LC_UUID) is invoked.
It turned out that the problem was caused by the default golang toolchain not producing a LC_UUID load command, which seems to be critical for the network privacy subsystem to determine whether the binary is allowed access or not.
Basically, yes, things can get weird when an executable doesn't include LC_UUID and that's an issue they need to fix in their toolchain. This is one example, but the biggest issue (in my view) is that it breaks any kind of automatic symbolication, since that UUID is how our system matches crash logs to symbol files.
Filed FB14587785 to track the confusing situation of the UI reflecting granted permission, while not working in practice.
It's a reasonable bug, however, IMHO the "fix" here should be to reject the extension as invalid at load time. Executable need to include build UUIDs.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
