Mitigations like running in a VM might protect your dev workstation. But not code you put into production that relies on third parties.
Mitigations like running in a VM might protect your dev workstation. But not code you put into production that relies on third parties.
VS Code isn't some kind of hobby project by a couple of dudes on laptops with nothing but the best interests of the community at heart. It's a flagship IDE produced by one of the most valuable tech companies in the world, released for free as a loss leader in service to very specific corporate goals.
When a tech behemoth releases a free IDE as a loss leader and it drives out all of the scrappy open source projects one by one, I think it's reasonable to hold that tech behemoth to tech behemoth standards rather than scrappy open source project standards.
Raymond Hill (of ublock fame) wasn't really impressed with how it is performed, but it's still much better than nothing (which is what MS apparently does).
VSCode is an IDE in name only, it's a glorified text editor, and pretty mediocre one at that. I in "IDE" stands for "integrated", like what you'd expect from JetBrains' products. Or even the real visual studio.
Or to make things more succinct:
* VSCode is a extendable code editor (like vim, neovim, Zed and Sublime)
* Jetbrains Rider is a fully equipped Integrated Development Environment (like Microsoft Visual Studio or its direct sibling Jetbrains IntelliJ IDEA)
And while extensions are optional within a IDE (and often solely used for increased productivity), more often than not they are a necessity in a code editor to even become productive.
"Integrated" isn't meant to contrast with a plugin-based system (otherwise JetBrains wouldn't count!), it's meant to contrast with a dev environment built out of a bunch of individual tools and terminal commands run separately.
How you know that?
Which is why I'm pretty confident in first party packages and don't install third party plugins from random authors.
You’d end up with Apple-style reviews and then people complaining about them. You can’t really win.
I made the point elsewhere, but this seems to fail in the face of Debian and Red Hat and Canonical who have been publishing mostly-secure distros of exclusively open source software for decades now.
There's a reason why MS and NPM get caught by this sort of shenanigans, but it's not "open source".
No, the reason Linux is safe and modern distributors aren't is the "packaging" step. Debian volunteers package software that they understand to be high quality via existing community consensus. You can't just show up to Fedora and say "ship my junkware app", you need to convince the existing community that your stuff doesn't suck.
And that's worked extremely well for decades now, going all the way back to 2BSD being shipped above V7 Unix. The reason MS and NPM et. al. abandoned it isn't just pure experience[2]. They don't want to wait for their repos to fill with good software, they want all the software in it now so that they don't get beaten by whoever their competitors are.
And this is the inevitable result. If you allow anyone to distribute software to your users then you allow everyone to distribute software to your users. And everyone includes a lot of bad people.
[1] With vastly more capability! The distro ships everything from firmware blobs and kernel drivers up through browser glitz and desktop customization. Talk about "attack surface"!
For the most popular package:
Debian: ~253K installs per month [1]
NPM: ~236M installs per month [2]
VSCode: ~158M installs total [3]
Obviously VSCode is hard to compare, but the most popular Debian package would need 52 years to achieve the total VSCode numbers so I'm sure it's safe to say VSCode beats Debian significantly on installs and NPM wins even more convincingly.
Ok, but let's take a look at how much code is shipping which was your metric:
Debian: 242k submissions per month for amd64 [4]
NPM: ~50k new non-spam packages per month, ~800k new version submissions per month [5]
VSCode: No data available
I don't know how VSCode compares, but clearly NPM beats Debian which makes sense because of how open it is and more importantly how many orders of magnitude there are JS developers vs Linux developers and how much more frequently they update their packages because the overhead is lower for creating a submission.
It's really easy to forget that the number of JS developers or people using IDEs is much larger than the number of Linux users. So NPM still beats Debian on this front. As for the security assumption and how good a job maintainers are doing, I'm not so sure on that either. The xz utils backdoor into SSH was found by a Microsoft employee (i.e. the community) not by Debian maintainers. It's not hard to imagine that the lack of notable security issues (particularly attempts recorded) actually indicates very little review, not that there's a higher bar because the maintainers are more talented or have better incentives for "reasons" - there's a reason Chrome was perceived as having better security than IE (it did - architecture was better) and STILL they see regular successful attacks bypassing all the mitigations.
Again, to reiterate in case the above got you triggered again - NPM & VScode have significantly more users than Debian and that creates economic incentives for attackers. The capabilities of a vulnerability matter less unless you're a state actor because capabilities do not track economic results as strongly. This has so much evidence it shouldn't even need this kind of explanation. Remember when people said that Mac had better security? Well turns out Apple is dealing with all the same vulnerability and spam issues on a closed down system when their popularity went up; again, economic incentives.
[1] https://popcon.debian.org/main/by_inst
[2] https://www.npmjs.com/package/lodash
[3] https://marketplace.visualstudio.com/items?itemName=ms-pytho...
[4] https://popcon.debian.org/
[5] https://blog.sandworm.dev/state-of-npm-2023-the-overview
But I'm not following how you get from popularity numbers to "attack surface". The latter is a term of art that reflects the amount of complexity on the "outside" of a software system that can be interacted with by an attacker. It correlates well with "amount of code". I don't see that it has any relation at all to number of installs.
But sure, let's use "amount of code" as a proxy. Debian has ~123GiB of source code [1] across ~65k packages [2] while NPM has 74 GiB [3] if I'm reading it correctly (other sources say 128 GiB) across 3.3 M packages [4]. Given that JS requires less code than C for equivalent functionality (due to a richer runtime & no memory management), any way you slice it, NPM is a much larger attack surface both in terms of number of opportunities and how valuable the attack is.
[1] https://www.debian.org/mirror/size
[2] https://www.debian.org/doc/manuals/debian-faq/basic-defs.en....
Fiscal responsibility: required
> Not merely a couple dudes in their bedroom doing this in their spare time?
Fiscal responsibility: optional
I would also point out, the malware-infested extension we are talking about presents more as the “two guys in a bedroom” model (though possibly a state-sponsored actor).