My use case is: I want to run multiple services on a Mac Studio, each binding to a different IP address, all using port 443. Ideally, I'd like to run them as a non-root user. Afaict, the options are: a reverse proxy listing on all interfaces (I'd like to avoid this additional network hop) port forwarding using PF wait for the issue discussed in this thread to get resolved and continue to run them as root in the meantime. I hope we get to see another Finally! :)

Thanks, Quinn! I've created an enhancement request and here's the bug number as requested: FB17818651. I apologize if the "if only" came across as a bit snarky. I understand that not having such a setting is probably the right thing for macOS in the usual context of a personal computing device for end users. However, in a server context (where I guess Mac minis and Studios are quite popular), it might be warranted. Not sure if this audience is a priority for Apple. As for Homebrew: I'm not a maintainer, but as far as I know, it only provides attestations for bottles (packages), and uses ad-hoc signing for the executables contained in the packages: https://repos.openssf.org/proposals/build-provenance-and-code-signing-for-homebrew.html#macos-executable-code-signing https://github.com/Homebrew/brew/blob/1f37a11b7946b6d770ecba66a487ba325b58e49c/Library/Homebrew/extend/os/mac/keg.rb#L40

Thanks! I hope there's a chance of a solution materializing during Tahoe's development. In the meantime, I'll probably revert back to launch daemons because the permission problem is worse than I thought. It's one thing when I have to log in using remote desktop to re-grant permissions after upgrading Prometheus, Grafana, Alloy, or other services, but it's another when I upgrade a runtime like Pythong or .NET. In that case, I have to figure out which services use those, restart them, and then allow access to the local network and private keys in Keychain. Running as root is already not great, but launch daemons often surface another problem: because they start so early in the boot process, network interfaces might not be up yet and some services don't properly handle that case. Technitium DNS, for example, falls back to listening on a default port on all interfaces if binding fails. I've filed an issue upstream and the next version will introduce a flag which instead terminates the process, so that launchd can restart it at a later time. There are other cases like this. Just mentioning this additional context in case it helps with prioritization :)

For posterity: the behavior seems unchanged on macOS 26.0 Beta (25A5306g). Binding to a specific IP still requires root permissions.