Actually, I'll do one better. For a rather large framework we are developing an engineer at DY introduced a somewhat similar problem. A binary was being installed, from a trusted source in this case but a binary was being compiled/installed none the less. It never made its way to an actual release and I personally took the time to change this approach so that we weren't installing binaries on people's machines without their permission. We now pre-compile and vendor. This approach likely isn't what Zed can do as in this case we can target just Intel/Apple Silicon machines but the point here is I recognized the problem and rather than just hand-wave dismiss it as a #wontfix I took responsibility for it and fixed it myself. It cost money, it cost time. I still fixed it because that's the right thing to do.
Vendoring the binary guarantees that I control what is running. It isn't installed, just run locally from the lib. I'll quote the OP issue on GH:
> Now I found that it downloads (here) even some proprietary binary from https://supermaven.com, i.e. unaudited and unauditable code, without any verification (except TLS)!
This opens Zed up to Man In The Middle attacks and Supply Chain attacks. And now that Zed has indicated that they won't fix the door is wide open to these vulnerabilities.
https://github.com/liveview-native/liveview-client-swiftui/p...
Compassion for those putting others in harms way is such a stupid take.