PSA: every package you install from any package manager from browser extensions to npm/composer etc presents the risk of malware. Because the open source community lacks the financial resources to vet every single version of every package. Demanding this level of security from software provided at no cost that relies on open contributions is wholly unreasonable. If you need that, buy an IDE from a company financially capable of ensuring security and accept the limitations of their offering.

Mitigations like running in a VM might protect your dev workstation. But not code you put into production that relies on third parties.

> Demanding this level of security from software provided at no cost that relies on open contributions is wholly unreasonable

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.

The marketplace isn't operated on a paid contract for vetted extensions. You vet the extensions you use. Most don't, and it's ok. Don't shift the blame and the cost on microsoft though, they don't have to offer it.

Yet Mozilla, for all the flak it gets, isn't paid a dime by its users, but does find resources to vet the most popular extensions. Everything I use is checked by them.

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.

What functionality or property makes JetBrains' products an IDE while VSCode isn't? Honest question, I've never used any of their products.

Paid JetBrains user here. What JetBrains gives you is self-implemented add-ons in their marketplace. These are perceived to have the same level of trust as the base product. Then there is the similar level of “might be malware” or “steal your infoware” from (possibly adapted) open source and third parties available on their marketplace.

As a example: Rider (https://www.jetbrains.com/rider/) - a IDE - comes with everything you could possibly need to build and compile .NET apps out of the box, while VSCode - a code editor - relies on extensions (and thus mostly the community surrounding VSCode) for this.

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.

I'm a big JetBrains fan, but this distinction is just silly. If you look at the way that JetBrains IDEs are packaged, the differences between IDEs all come down to extensions—which are enabled by default, which are available to install at all. IntelliJ Ultimate can be made to have all the features of PyCharm with the right extension combo. And occasionally they break out a new IDE by taking an extension and making it no longer available for installation elsewhere (like RustRover). The entire architecture is one of plugins.

"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.

Good point. In the old times if someone had Eclipse but installed plugins for different language than Java we wouldn't suddenly downgrade Eclipse that it is a text editor.

Apples to oranges or should I say Advertising Revenue vs. Freemium Revenue models

>Everything I use is checked by them.

How you know that?

> 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.

Which is why I'm pretty confident in first party packages and don't install third party plugins from random authors.

> I think it's reasonable to hold that tech behemoth to tech behemoth standards

You’d end up with Apple-style reviews and then people complaining about them. You can’t really win.

You do realize this is Microsoft we're talking about here? Not merely a couple dudes in their bedroom doing this in their spare time? I guarantee you that a non-zero percentage of the code in VSCode was paid for.

Who ever paid to use the extensions marketplace?

I meant on the development side, not that end users paid for anything.

Then why should end users expect anything? Microsoft is already paying for developpers.

Then they can pay those developers to sandbox vscode extensions at the very least. I like using vscode sometimes but I'm sure as shit not going to use it if my work bans installing extensions due to security risks.

> You do realize this is Microsoft we're talking about here?

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).

> Because the open source community lacks the financial resources to vet every single version of every package.

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".

Because the attack surface is smaller and more difficult to extract value out of. I think it’s been shown time and time again the more motivated your attacker the more difficult it is to defend and very visible popular platforms see more attacks. NPM and MS represent drastically larger platforms.

Uh... no. There is far (far) more code[1] shipped in the package repository of any Linux distro than in all the world's vscode extensions. Are you being serious? NPM arguably gets a little closer, but only a little.

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"!

Remember, when we're triggered our reading comprehension goes down and we confuse emotion for facts. Did I say they ship more/less code? No, first I was talking about the user base size and the economic incentives for malicious users.

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

The "triggered" bit is just flaming. Please stop that.

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.

I originally used attack surface imprecisely in terms of how many people you compromise with a single vulnerability. In other words the economic value of the attack. But also in the formal term of art, it's still true that NPM has a larger attack surface with many more weak points than something like Debian has. VSCode is trickier since it's a single application, so may not be from that perspective. However, it is basically running Chrome so it is still quite a large attack surface area.

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....

[3] https://replicate.npmjs.com/

[4] https://en.wikipedia.org/wiki/Npm#Registry

It presents a risk sure. But your browser sandboxes those extensions. VSCode runs extensions with the same permissions that VSCode itself has.

Remember, this is Microsoft! A friend told me of a fairly major corporate firm that found MSFT had arbitrarily pushed an AI tool to run on their SharePoint, scooping up site data outside of any formal agreement to do so. MSFT are no doubt covered by a general agreement but this seems underhand/inept and yet a remarkably common flaw in their approach (I've seen similar behaviour with Teams apps)

I was going to point this weird part of their comment too.

Reminder that the Open-VSX extension registry exists: https://open-vsx.org

Idk if they removed the malicious theme (or if they have it at all), but if MS isn't doing anything beyond just responding to user reports, you might as well switch to an open registry that probably does the same level of security work, and avoid giving them yet another monopoly.

> you’re running arbitrary third party code on client machines without any form of sandboxing. This is a level of security you would not deploy into Azure, so why is “run arbitrary 3p code on someone else’s machine” appropriate for VSCode?

More and more, I am starting to think I need to run my development environment (for both work and personal projects) in a VM.

I am on MacOS, so UTM or Parallels would work pretty well I think. Sadly, I think my work explicitly forbids us from running VMs or accessing our services from them.

VSCode in cloud would be great, GitHub tried something similar with GitHub.dev , I haven’t tried it in a while but it didn’t feel quite ready at the time, maybe things have changed

Try https://vscode.dev

You can append a Github repo to the URL to open it: https://vscode.dev/https://github.com/facebook/react

> If you’re relying on the community to alert you to the issues in the marketplace, perhaps you’re not investing enough in auditing popular extensions yourself?

I think that's sort of unfair. Of course MS should be relying on the community! That's arguably the best single practice for detecting these kinds of attacks in open source code. Objectively it works rather better even than walled garden environments like the iOS/Android apps stores (which have to be paired with extensive app-level sandboxing and permissions management, something that editor extensions can't use by definition).

The reference case for best practice here is actually the big Linux distros. Red Hat and Canonical and Debian have a long, long track record of shipping secure software. And they did it not on the back of extensive in-house auditing but by relying on the broader community to pre-validate a list of valuable/useful/secure/recommended software which they can then "package".

MS's flaw here, which is shared by NPM and PyPI et. al., is that they want to be a package repository without embracing that kind of upstream community validation. Software authors can walk right in and start distributing junk even though no one's ever heard of them. That has to stop. We need to get back to "we only distribute stuff other people are already using".

I think you missed the part where I’m asking why the extensions aren’t sandboxed whereas they do invest into sandboxing when it comes to renting out their own machines in the cloud. Even browsers try to do sandboxing of extensions. It’s a jarring disconnect and VSCode is well beyond the prototype stage at mass adoption - the lack of sandboxing is confusing and worrying.

> Help me square this circle

Sure. As a general rule, you get what you pay for.

Lmao why should they have to spend money auditing random 3rd party extensions that you choose to install? VSC is free, we're not paying for it.