121–130 of 183 posts
I don't get why having a modal for each tool asking for consent is too hard.
I don’t want that. Popups are one of the reasons I stopped using VSCode. They drive me nuts. Just let me write code.
Why is showing the release log the default for so many things? Is the average user really going to read them?
It makes you wonder what they are doing with all that telemetry
[flagged]
Downloading and executing untrusted code is a security vulnerability. If a library does so accidentally, avoiding such an accident should be the primary focus of the report. If a library does so intentionally due to an accidental error in design of a feature, then the report can focus on how to provide the same functionality without introducing a security vulnerability.
This is neither of those cases. This is a feature whose core functionality, automatic download and execution of arbitrary code, cannot be introduced without causing a security vulnerability. This trade-off, in which marginal functionality is introduced by sacrificing any and all security, was a decision made at some point.
> but would it have killed the person reporting it to have formulated it something like "I appreciate the convenience of automatic downloads but I'd prefer to be able to opt-out because of [...]".
This phrasing is not equivalent. Stating "I appreciate the convenience of automatic downloads" does not seem accurate at all. Nowhere does the convenience show up as something that the reporter appreciates. Stating "I'd prefer to be able to opt-out" implies that an opt-out is sufficient. Avoiding a security vulnerability based on a per-user opt-out is something that should only be done for a hotfix until a better solution can be implemented.
I could see the report being updated with a minimum list of design changes that would be necessary for the feature to be implemented in a safe manner: "While locating and recommending a package to be downloaded is convenient, the download must only be performed when the user explicitly approves it, with the user informed of the recommended package, its version and checksum, and the download URL prior to any download. Anything less than that is a security vulnerability." However, I don't fault the report for not doing so, as a reporter may not be familiar with a project's design roadmap. Describing an existing feature's design as "completely unacceptable" is sufficient.
I don't really see the big deal here. Who wants to approve and configure all of their language servers? If you open a file for that language, is there ever a time you would deny the download? I just don't want a huge amount of popups like VSCode. Also, the binaries are downloaded from their release on github. As long as that is secure I don't see a problem.
> I don't really see the big deal here Here's an idea: someone sends a dev at some company, or even a freelancer, some code. Code references a module with a malicious npm package (say, with a postinstall script). Dev opens it in zed Now, my untrusted code is running on your machine, probably without your knowledge
Unless you’re auditing everything while taking Trusting Trust into account, you’re drawing the line somewhere saying “ok I can’t be bothered past this point verifying”.
… everyone has a line somewhere on the trust-but-verify spectrum
I don't really see the big deal here. Who wants to approve and configure all of their language servers? If you open a file for that language, is there ever a time you would deny the download? I just don't want a huge amount of popups like VSCode. Also, the binaries are downloaded from their release on github. As long as that is secure I don't see a problem.
GitHub release builds provide no whatsoever guarantee of having been built by GitHub from the corresponding source, if I remember correctly
1: https://github.blog/2024-05-02-introducing-artifact-attestat...
Being it binary or not, it doesn't make any difference. It's the "modern times" craze about plugins pulled from different unauditable, unknown sources. The fact that it is on GitHub or any other "publicly available" source it is irrelevant. I keep using vim and Kate and manually install anything I need form my distro (Arch Linux) repos. If it is not there, then, sorry I cannot use it.
This is a fallacy though, unless you’re also code reviewing all of the Archb libraries you pull down
I don't think it has to be this way. I think we can have both better compartmentalization and tighter workflow integration without having it becoming a part-time job.
Here is my ongoing attempt at addressing the issue, currently scoped for neovim[0]:
https://github.com/legobeat/l7-devenv
(I did share this to crickets as a Show HN the other day, hope it's on-topic enough to OK to reshare here)
[0]: The same framework should, at least in theory, be extensible to do something similar with Code/VSCodium. While working on this I realized there is some overlap with their Dev Containers and am yet to look into if and how one would run those in a similar fashion and if they could be leveraged to the same end