431–440 of 488 posts
Note that VS Code is built on Electron and it is a pain to sandbox because Electron has (had?) SUID sandbox helper, and you cannot run SUID binaries in sandbox easily. Sandboxing on Linux is extremely difficult task.
Don't build your ide on electron then.
Earlier quoted context omitted.
You can’t attack them that easily because of the different publication method. Emacs, Vim, and Sublime have a pull model (like linux distros), not a push model. Meaning you add your repos to the package hub, you do not upload an archive to them. The Hub will pull in you changes (or the plugin manager will do so). The only way in is to take over the repo itself.
Not sure how Vim and Sublime work, but for Emacs, publishing to MELPA is absolutely a push process, where you open a PR to MELPA's repo with a recipe for your new package; and, once it's accepted, every commit to your repo results in a new package build on MELPA's servers that Emacs users will get when they update / install the new plugin.
Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintainer would be quite surprised to see a new commit they’ve not approved of.
Earlier quoted context omitted.
Running code isn't the problem. The fact that (almost) all code runs at the same security level is. You regularly run tons of untrusted code when visiting websites. That code can't wreak havoc on your machine because it's well-sandboxed. Yet, if we advocate for sandboxing in more places, the "gun nuts of tech" scream about monopolistic practices and taking away user control.
Yes, because sandboxing gets us unusable OS like iOS or Android. It isn't a solution. Perhaps the gun nuts are right then. Better be a gun nut than a Google employee, probably.
Earlier quoted context omitted.
Zed is even worse about arbitrarily downloading random stuff from random websites and executing it
How so? Part of what seemed good about Zed was that extensions have explicit permission controls.
I've been telling less computer literate folks not to install random stuff since the nineties, and I can't understand how many devs are doing just that these days. I used to work in security auditing, and it makes me feel pretty jaded to think of the gigabytes upon gigabytes of random stuff that just gets pulled in from everywhere in IDEs, package managers, build pipelines and container images. At least back then the…
Answer: Because the "random stuff" (plugins for VS Code and other IDEs) solves real problems and nothing bad happens most of the time. Almost no manager will sign-off spending time on building stuff in-house if its available "for free". This is also in no way a new thing. How much code was written in notepad++ in the '00ies? Did anyone bother to check if the plugins did sth. malicious? We also used some weird closed-…
Aaand this is why AI is taking our jobs and we all rightfully deserve to be laid off. This utter lack of risk awareness and care for quality is what created the need for autonomous agents to dig through and build upon man-made slop.
Honestly, I find it rich that we’re the ones who think that AI is the one that’s producing slop. Give any agent clear harnesses and it’ll produce better code than a human would close to 100% of the time. That’s still as indeterministic as the way you used “most of the time”, but the deviation tends to be smaller and the quality and rigor is much higher.
Earlier quoted context omitted.
Not sure how Vim and Sublime work, but for Emacs, publishing to MELPA is absolutely a push process, where you open a PR to MELPA's repo with a recipe for your new package; and, once it's accepted, every commit to your repo results in a new package build on MELPA's servers that Emacs users will get when they update / install the new plugin.
It’s not. The developer never build a package and then upload on melpa. Melpa will fetch the needed files and build the package. It’s not truly secure, but an attacker would need to publish a new commit and wait for quite some time for people to update. Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintai…
1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point.
2. Wait for people to pick up this new extension, while it's still benign.
3. Push the malicious version to my own GitHub repo. MELPA will automatically pick it up, build it, and package it.
4. Anyone updating their Emacs packages from MELPA or installing it from MELPA will pick up this malicious version.
Now, this does require that the malicious code is visible on the extension's GitHub page; I'm not sure if this would be true on VSCode as well.
I've been telling less computer literate folks not to install random stuff since the nineties, and I can't understand how many devs are doing just that these days. I used to work in security auditing, and it makes me feel pretty jaded to think of the gigabytes upon gigabytes of random stuff that just gets pulled in from everywhere in IDEs, package managers, build pipelines and container images. At least back then the…
Answer: Because the "random stuff" (plugins for VS Code and other IDEs) solves real problems and nothing bad happens most of the time. Almost no manager will sign-off spending time on building stuff in-house if its available "for free". This is also in no way a new thing. How much code was written in notepad++ in the '00ies? Did anyone bother to check if the plugins did sth. malicious? We also used some weird closed-…
Some big corps resort to a different tactics: they ONLY allow in-house tools. IDEs, communication tools, everything you need on a daily basis, they make in-house tools for that. It costs a lot of money but they care about security.
The security model, or almost lack of any whatsoever in VSCode drove me to only install MSFT extensions, then use Code Server in a docker container, but I decided I didn’t like using my editor in a browser. Finally I have decided to start using Zed, which isn’t perfect on the security front, but much better IMHO. The combination of WASM extensions, and the ability to put language servers, etc, in dev-containers seems…
Wait, how do you arrive at the thought that Zed is more secure? The one time I gave it a try, it tried to silently run npm -- yes, THIS[1] npm -- in the background without telling me, and I noped the heck out. Did I miss something? [1] https://www.reddit.com/r/programming/comments/1tapmvi/mass_n...
On my machines, the "languages"/"node" directories for zed are empty and owned by root and the lsp servers are provided by nix. But you could also pin known good versions with npm.
As far as I know Vscode has no equivalent way to do this.
Earlier quoted context omitted.
Your comment implies that you've somehow misunderstood my comments and thus think that I am using Microsoft's hot garbage text editor with a million plugins. I can assure you I am not.
Your comment came across as sarcasm directed at aa-jv's position that folks are lured into the VSCode abyss and stay there because their comfort level won't let them leave, while VSCode - meanwhile - continues to be a huge security liability for any project where it is used.
The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".
VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.