amluto
a year ago
In some sense, this ought to be an opportunity. VSCode’s ecosystem is, in many respects, quite weak:
- 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.
sevensor
a year ago
VSCode also, by design, obscures what’s really going on on the development environment, so that when I help a VSCode user who gets stuck, they often don’t know what computer they’re logged into, where their files actually are in the file system, which Python interpreter they’re using, what HTTPS_PROXY is set to, and so on. The ssh extension also spins up a server process for every client a user connects, and it seems a bit inconsistent about preserving state across disconnections. All in all, I spend a lot of time helping people fix problems they’ve made for themselves by using VSCode.
spencerchubb
a year ago
What kind of set up do you use? This does not resonate at all with my experience of vs code
zdragnar
a year ago
Presumably, this is talking about some remote devcontainer configuration. None of that really applies to using vscode locally, at least not any more than any other editor.
shaklee3
a year ago
The bottom of the screen says exactly what you're connected to, so I'm not sure what they're referring to.
tikkabhuna
a year ago
> - The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
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.
EasyMark
a year ago
All these same things are true for emacs/vim/CLion plugins as well. You kind of either have to accept the risk cowboy style, do something in the middle (maybe only allow very well known extensions from source you trust), or live without the extensions.
spacemanspiff01
a year ago
Can't you host your own extension marketplace?
doubled112
a year ago
Then you have other problems. Maintaining the store itself, obtaining the extensions people want, and keeping the extensions up to date adds some overhead.
Looks like it should be possible, although I have no experience doing it myself.
phillipcarter
a year ago
Sounds like that's the price your org is willing to pay for your its flavor of Infosec.
tjoff
a year ago
The clangd extension is much better for me, assuming that you have or are able to generate a compile_commands.json (at least easy in cmake) and point clangd to it.
ReleaseCandidat
a year ago
There are generators for the compilation databases that work with Makefiles and other build systems, like Bear: https://github.com/rizsotto/Bear
Ragnarork
a year ago
Came here to suggest Bear as well, very handy piece of software to generate the compilation database in a mostly tool-agnostic way.
chpatrick
a year ago
I agree VS Code + clangd is probably the best C++ development experience I ever had.
theptip
a year ago
How does it stack up vs. CLion?
eulgro
a year ago
It doesn't, CLion is way better.
chpatrick
a year ago
I used CLion before I switched to clangd + vscode and it was orders of magnitude slower.
tcbawo
a year ago
What does it do better?
okl
a year ago
One problem I always had with VSCode, is that it seems to fill up its autocomplete suggestions with "near-string-matches" from files all over the project. The jetbrains tools are quite strict in that regard and won't propose random string matches that don't fit semantically.
digitaltensor
a year ago
That doesn't sound right. clangd should (and does) only suggest semantically valid suggestions. It's also much faster than the CLion's own C++ engine, though that might change with CLion Nova.
chpatrick
a year ago
CLion was what I used before and it was way clunkier than VSCode with clangd. Complicated libraries like CGAL just weren't usable for auto-complete, but were instant with clangd.
txdv
a year ago
I recently tried clangd with nvim and it was so good
monsieurbanana
a year ago
> The client, accessing remote repos, is wildly insecure, by design
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.
alexhutcheson
a year ago
If you want to be cautious, I have somewhat higher confidence in the versions of Emacs packages published on the Debian repositories[1] than the ones on ELPA/MELPA.
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...
monsieurbanana
a year ago
That's a bit of an understatement, about 1% of all emacs packages are in there :)
amluto
a year ago
vscode tunnel is already a massive step up from vscode remote SSH here.
diggan
a year ago
> Extensions are not sandboxed
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...
Sayrus
a year ago
Extensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or definitions, ...) and on your filesystem (SSH Config, Kubernetes config, Config folder in your home, ...). Sandboxing these extensions is not easy unless everything is configured within VSCode which is rarely the case.
As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
iLemming
a year ago
Extensions (in Emacs lingo we call them 'packages') are not sandboxed by design. Because unlike VSCode, you are allowed to override any, just about any part of a package's code. You can, for example, grab a command introduced in a third-party or a built-in package and override only specific parts of it without having to rewrite the entire thing.
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.
miohtama
a year ago
Please correct me if I am wrong but the only application (class) that currently sandboxes extensions is a web browser. So the bar is pretty high.
Sandboxing does not come for a free, as it creates more complex development APIs and a performance hits.
CraigJPerry
a year ago
Definitely.
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.
dumbo-octopus
a year ago
And happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
essentia0
a year ago
not only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.
dumbo-octopus
a year ago
Sure, I’ve even made a handful of those myself. I contrast them with workspace extensions that run on a (possibly remote) host with full access to subprocesses/etc.
amluto
a year ago
VSCode could shove the entire extension, third party binaries included, into a sandbox, Docker-style. And “give this extension Internet access” could be an option when you install it, with the default being “no”, and a bit warning if you want to override that default.
For all that the Docker ecosystem is somewhat of a mess, it seems more than adequate for this use case.
diggan
a year ago
> into a sandbox, Docker-style
Nope, docker alone/by itself is not a sandbox, at all. Not built for that purpose, nor suitable for that purpose.
pjmlp
a year ago
I am still waiting for many Windows extension scenarios that only support in-proc COM written in C++ to finally support out-proc COM with .NET, regarding how the whole security story is going on.
ReleaseCandidat
a year ago
Yes, their C++ LSP isn't really good and I've heard C# isn't good either - but that's because they want to sell Visual Studio too. But especially "Remote SSH" and "Dev Containers" are so called game changers. And their Typescript and Python extensions are actually good.
neonsunset
a year ago
C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) itself - this is what the base C# extension[1] uses. Both of these are licensed under MIT.
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)
easton
a year ago
Lately they've begun embedding the same C# analysis stuff they have in VS into VSCode if you pay for the license. I haven't used it in anger (long since left for Rider), but it has come in handy when troubleshooting people's VS issues at work from my Mac. The test explorer now blows up in exactly the same way in VS and VSCode :)
slowmovintarget
a year ago
A wild Emacs appears...