The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].
[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...
[1]: https://github.com/dotnet/vscode-csharp
[2]: https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
Who's the best kid in the block regarding third-party extensions security?
There's really not much standing in front of a supply-chain attack for my editor of choice, emacs. Most people use a community extensions aggregator that also directly fetches from git repositories. The only slim advantage we have is that I'm sure a much higher % of emacs users would actually look into the source code of the extensions they pull.
The downside is that not every package is packaged for Debian, and the versions are a bit stale.
https://packages.debian.org/search?keywords=ELPA+&searchon=n...
This is a big concern for our Infosec team. There is no middle ground between open access to every Extension on the marketplace or locked down and Extensions are installed via local files. The latter being a significant overhead in maintaining VSCode.
Looks like it should be possible, although I have no experience doing it myself.
This is quite surprising to me if true. Microsoft has for years touted "Security is everything and the single most important thing right now", yet something that basic is not taken care of for the most security minded audience, and for the audience with probably the biggest impact in case ssh-keys and alike gets stolen?
People randomly installing extensions (and Visual Studio Code suggesting random extensions by "language support") starts to look a lot worse than I thought. Guess I'm lucky I never jumped aboard the Visual Studio Code train...
As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
Of course, in many cases that can make your entire setup brittle - i.e., what happens when the package author decides to change some functionality that you carefully and tightly integrated into your system? At the same time, there's enormous, unmatched flexibility for making your own rules of the game - there's nothing that comes even close. You can change a function to do things that it was never initially designed for. For example, if there's a command that lets you perform GitHub search and open results in the browser, you can advise that command to change the behavior and instead of opening the results in the browser, send that data to an LLM and display it in a text buffer. You wouldn't have to rewrite the entire command; you would only have to override a specific part of it. In Vim, you'd have to rewrite the entire function. In VSCode, you'd likely have to make a separate extension. In Emacs, you wouldn't even have to save the damn thing into a file - you can write it in a scratch buffer and immediately try it out.
Sandboxing does not come for a free, as it creates more complex development APIs and a performance hits.
Would still be nice to have the option to opt into, for example, running as a WASM isolate - given the option of a robust sandbox, some plugins will find it desirable to migrate and gain the secure badge or however isolated plugins are marked for user identification.
But There are plugins where it’s going to be too much of an uphill battle to move to that model though. I still think on balance having sandboxed plugins, however they’re implemented, would be pretty nice.
For all that the Docker ecosystem is somewhat of a mess, it seems more than adequate for this use case.
Nope, docker alone/by itself is not a sandbox, at all. Not built for that purpose, nor suitable for that purpose.
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.