My God, the list of npm dependencies some projects I've worked on had. Endless. Anyway, it could have been me. I don't inspect vim plugins before install, generally. Security is hard. Even if you're an expert, it's a lot of work.
As a bare minimum security measure, when using plugins (all 9 of them), my Vim runs in a bubblewrap sandbox with only my project folder mounted as writable. Network and IPC access is completely disabled. It is secure enough to stop practically all non-targeted attacks. Generally I try to install plugins whose authors I know. And whenever I update them (once a year) I re-read the entire source code. Some small plugins…
So it's Emacs, but we want features and not to be locked. Don't run propietary crap, trust Elisp repo like ELPA and NonGNU and you will be mostly safe.
As I understand, VSCode extensions can run arbitrary shell commands and Microsoft didn't add any security measures (e.g. asking a user for confirmation). In this case it is only a matter of time, motivation and perseverance until all users who use extensions will get a back door. Of course this applies not only to VS Code, but to any other software which allows to install third-party extensions like browsers, Gimp, I…
Why should we? Repos like ELPA, NonGNU and CPAN are trusted enough.
I have been leery of VSCode for this reason. The bare product isn’t very special, so you have to download extensions to get the functionality you need. However, there is nothing keeping the extension from communicating. Suddenly, you get malicious extensions that leak data. It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk.
replace VSCode with any other code editor and it will still work.
Vim, Emacs, Sublime are all examples of bare products that aren't very special unless you add extensions that could potentially leak data and run arbitrary commands.
the fact that only a couple extensions have been found leaking some data involving only a few thousands installs, it's honestly a very good record if you ask me.
Some people have argued that we should work inside expendable and tightly restricted VMs when doing anything that involves fetching packages from a repository using a package manager. I used to feel that was quite an extreme position but it does make sense because the risk we're discussing is really a consequence of two systemic vulnerabilities. Mainstream desktop operating systems have weak security models that aren…
>Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world
Stop using propietary software first, then we will discuss your "security" rants.
Perl users have been using CPAN since forever, so did LaTeX users with CTAN.
Ditto with Emacs users with ELPA and NonGNU. No issues with addons.
This is even more true considering that VS Code sends telemetry by default (opt-out), making it as a whole "malicious PII stealer code" in the article's terms.
Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.
> Not really, if you are aware of that and have been actively been opting out of vscode telemetry
This article is a good example of how to write a misleading headline. They found 3 extensions, one of which has 45k downloads (because it name squats on a popular package), and another with 1000 installs. The 45k dowload extension (Darcula Dark) collects some data that I would define as telemetry, and the python-vscode extension which is clearly trying to hide what it's doing. Now, whether you define telemetry as mal…
Name squatting always betrays malicious intent. No benefit of the doubt is owed to anyone practicing it.
As I understand, VSCode extensions can run arbitrary shell commands and Microsoft didn't add any security measures (e.g. asking a user for confirmation). In this case it is only a matter of time, motivation and perseverance until all users who use extensions will get a back door. Of course this applies not only to VS Code, but to any other software which allows to install third-party extensions like browsers, Gimp, I…
Indeed. Professional woodworking equipment can also cut you, but that’s a risk we accept as we know their developers also care more about providing a tool that works and can be used responsibly by trained professionals. Yes we could insist everyone only hands us straight jackets in padded rooms, but I’m not sure that’d be a good thing.
For over 20 years now, professional woodworkers have had SawStops, devices that literally use an explosive charge to ram a block of aluminum into the blade of a table saw when it detects that the blade is touching something that might be a human body part. These are $50+ devices that destroy themselves on use (and often destroy the $50+ blade they’re used on), they have a high false positive rate, and yet they’re still in heavy use and very popular with professional woodworkers. Table saws also have riving knives and sleds with clamps, both to prevent kickback. All of this on top of constantly educating woodworkers to be responsible and use push blocks instead of their hands, to boot. All of these safety features exist on table saws because we did educate woodworkers on how to be responsible, and we still saw that the average table saw will cause more than one injury in its lifetime. I’m actually really glad you brought up woodworking because table saws are a perfect example of how we saw “this is risky, be responsible” was inadequate.
Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.
I'd say VSCode is a bit different in who it's aimed at. Only because it doesn't work for a consumer product doesn't mean this wouldn't work for VSCode. Also it might be good to be more specific. E.g. don't ask for all permissions at once, instead if the app starts talking to telemetry.endpoint.com it has to ask for these specific permissions at that point. Then the user can see, hey this is requesting access to this…
Are VSCode users really that much more diligent? Are you auditing the source code for every extension you install? Do you even know if the github source is the same as whats hosted on the plugins repo?
The only real solution I can see is only installing plugins from large trusted entities.
Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.
Users here are experienced developers, so I think it's not such a big deal. In context, a theme should never need network or file storage access, so you could upfront block those for that type of extension. You can also have policies like "network access is okay but file system and network access together needs approval".
I find I very quickly tire of having to think about this. You think "A theme shouldn't require file storage access" and then spend an hour looking up why it does and find out there is actually some strange but totally legitimate reason for it. And every time that happens, you lose a little bit of will to care about what permissions something requested.
There used to be a period where many android apps would explain in the description why they needed certain permissions. Those days are over.