Comment by cyberax
> Not sure what permission you're referring to or what your curl script is trying to do but `/opt/homebrew/opt/curl/bin/curl http://www.google.com` works just fine on Tahoe from both iTerm2 and ghostty.
Mwwahahaha. Yep. Curling something neutral like google.com worked fine for me as well. That's how I was verifying that everything was OK.
Now try to do "curl https://192.168.0.1" (or whatever is your local router's IP). It will trigger this request: https://imgur.com/a/tMAApfB
The permission in question is called "Local Network", you can find it in the "Security" section in the control panel. Yeah, their names don't match.
Oh, and negative entries are NOT listed in that panel. So if you deny the request, there is NO indication of that. Anywhere. Logs will also be empty.
> This is IMO the correct behavior. If something asks for permission and it's not explicitly granted, then the default should always be denied.
The keyword is SILENTLY. The permission requests should be logged and made available in a central location, where they can be reviewed.
It's literal recursive WTF. When you start looking at it, it gets worse and worse.
So I thought that might be the dialog you're talking about which is why I thought it was weird that ghostty didn't have it and curl seemed to work just fine. I also could swear that it did show you rejected apps in the list just with the permission turned off.
After experimenting a bit, it seems like:
1) You're right that it doesn't show the rejected apps in the list. Seems like the only way to find that is to query the tcc sqlite db.
2) The permission does apply equally to the built in `curl` as it does to the homebrew installed curl.
3) What it doesn't apply to apparently is the gateway address on your network, regardless of which app you use.
4) It also doesn't apply to all "private" IP space addresses, just ones that are on your subnet. So for example, I have an IOT subnet on my network on its own VPN with a route in the gateway for accessing it from some specific devices on the primary LAN. Without the permission, I can ping and curl (with both the built in and homebrew versions) all of the devices on the IOT subnet. But I can't ping or curl (again with either version) any of the devices on the LAN subnet. Turn the permission on and I can hit everything on the local subnet fine from all the devices.
5) I also validate that the above rules are true even for an application (alacritty in this case) that had never been given permission (in case setting and then removing the permission did something odd)
> The keyword is SILENTLY. The permission requests should be logged and made available in a central location, where they can be reviewed.
This I agree on, the rejected apps should show in the privacy permissions, even if in a collapsed tab/pane so that you can review later. I could swear it used to do this, but maybe I'm thinking of iOS which does do that.