Earlier quoted context omitted.
I won't say "you can take my VS Code from cold dead hands" or anything, but it is a very good tool, and Microsoft hasn't yet fucked it up the way they have so many other things. I guess I'd say "you take my VS Code ... willingly ... but only after M$ fucks it up and makes me not want it anymore (like they've done to everything else they acquired)".
Vs code is a weapon, designed to fracture. It being “good” is a weapon as well. https://ghuntley.com/fracture/
GitHub confirms breach of 3,800 repos via malicious VSCode extension
251–260 of 488 posts
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#252All used techniques and mitigation strategies, including this one: https://npm-supply-chain-attack-techniques.pagey.site/
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#253Earlier quoted context omitted.
Agreed. What's frustrating is that we have models for how sandboxing can work and instead of investing efforts into nailing that experience, the OS providers are prone to turning it into a monetization/lock in layer instead. My VLC and VS Code should have an OS native way of being limited to particular functionality. But when the OS providers implement the sandbox, they center it around an App Store and restrictions…
That exists on linux under flatpak, but it requires Wayland and Pipewire. Also many packages just request full system permissions rather than update to work in a sandbox. It's in the works and one day we will have it but progress is slow.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#254Earlier quoted context omitted.
Because it's hard to create a system that is both sandboxed and powerful. You can't have an extension system that allows a plugin to run a locally installed linter or view the status of docker containers but can't execute something malicious. I do agree though that it is incredibly important to start taking sandboxing seriously. But there is a lot of difficulty and friction, and most of the users will scream and cry…
> You can't have an extension system that (...) Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving . That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both…
You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#255Earlier quoted context omitted.
I really hope this pushes users (here: devs and maintainers) to decrease their reliance on Microsoft and especially stop outsourcing security to them. Migrate off vscode already.
> Migrate off vscode already. It's not the IDE, though. Any extensible, customizable display editor can be coerced into behaving badly by installing external code. Even this one: https://www.gnu.org/software/emacs/emacs-paper.html The root(-ish) cause here is the ease of publishing and installing extension code, and in particular the fact that there's no independent validation/verification step between the upstream a…
But I think only VS Code (And Jetbrain's ones) is so pushy about installing extensions. With Emacs, you actually have to go find them and install it. And then you actually have to make a conscious effort to update them. Same with vim. I'm pretty sure VS Code enable auto updates. And I would guess the people publishing Emacs's package and Vim's plugin are way more conscious about security.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#256Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#257Someone scold me if I'm wrong but this is really worrying. Threat actors with Github's internal code means a huge acceleration in vulnerability discovery for the one platform where everybody warehouses their code. How is this not really, really bad?
Security researchers identified a series of exploitable vulnerabilities in github.com by using LLMs to review the compiled GitHub Enterprise Server binaries: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-38...
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#258Finally 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 like a great step forward.
I hope Zed continues to improve their extension and language server security model. Actually I hope VSCode does too, but honestly, I am not optimistic.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#259Earlier quoted context omitted.
Internet access. An editor extension does not need it.
Most sandbox systems today, take seatbelt from Apple for instance, only strip permissions. If your extensions without internet access calls a tool that needs it, boom access denied or worse, weird network issues. One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.