Open jfhgdfksjsd opened 4 weeks ago
Thank you for the bug report This is a (another) known Apple bug in macOS Sequoia, impacting any tool that leverages macOS' Network Extensions 😠...Apple is (supposedly) working on a fix.
Ah I see! I feel better knowing this is tracked, even if it takes a while (really wish there were an easy way to downgrade without having a backup). Feel free to keep this open or close since the issue is more upstream, whatever makes most sense for the project. Thanks again!
They seem to have fixed this issue in 15.0.1
Just updated to 15.0.1. The "fix" doesn't not look like the old (pre Sequoia) way, but rather just as a whitelist of everything... After having removed all rules related to eg. iTerm, and single commands like curl
, I'm still able to run all commands without approving anything. Also other Applications on my machine are now able to startup and connect without any connection request poping up...
Also other Applications on my machine are now able to startup and connect without any connection request poping up...
+1 All Apps
Heya, I hit an interesting issue after upgrading to Sequoia.
On Sonoma, in both the regular Terminal and Warp terminal, I used to be able to
ping
,curl
,brew install
, etc. so long as those commands' destinations were in my rules.Now, on Sequoia, I am forced to give permission to the terminal app itself, whether Warp or Terminal. This is not ideal, as I want much more granular control: e.g., pings/curls should be allowed, but the Warp binary itself sending telemetry probably not.
So there is an apparent change in attribution of network requests to processes. Any idea if this is a purely Sequoia issue, or an issue with how LuLu interacts with the network stack in particular?
I'm aware of the network-filter-related issues reported for Sequoia, but this seems a bit different (attribution, not packet corruption, though I've had plenty of that now too). Would be curious to learn more. Thank you!