It’s not clear to me, are these issues on the local or remote vs code instance? If remote, I understand elisp tramp is a lighter touch as far as dependencies go, but is the attack surface all that different? (That is, does the remote node binary have any permissions a user running arbitrary ssh clans wouldn’t?)
The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?
Emacs Tramp just uses whatever SSH access you already have to a remote host, to copy files back and forth. It may use scp or sftp if the remote host advertises the protocol, but it does not install anything or invent any of its own protocols.
Yeah, I know. I'm not talking about tramp. What I'm saying is that you could do precisely the same thing vscode does, probably without adding any new code to emacs, as long as the client and server architectures matched. The client would just send its own elisp interpreter across the wire and run it, giving itself a remote repl you could have it run anything in.
That would, of course, be just as terrible an idea as when vscode does it.
I don't see any reasonable alternatives that can support what VScode does, like running extensions that aren't installed locally. Maybe those features aren't something you want, but they're part of the product feature set.
I believe extensions are actually installed on the host itself! At least when I use vs code remotely it shows "install on xxx" for each extension if I haven't installed it yet
One perspective is to think of these as things that a modern OS should provide as a standardized feature, and VSCode is just working around the fact they don't exist. It's crazy to think about but the kernel itself could have a webserver (or other protocol) with encryption and auth that let you directly control the entire machine through EBPF. It could be an entirely different paradigm for client/server remoting. Also a security hole you could drive a death star through.
Honestly, I'd love a terminal based editor/IDE that is essentially a shameless clone of VSCode.
nvim showed me that it's possible, with mouse events, right-click context menus, and a rich editing experience. I did genuinely try to transition to nvim but I use my mouse a lot; resizing panels, using the file tree, copy/cut/pasting files in the file browser, tabs, etc.
That's not to say nvim is bad, but after hours of configuration, I personally found myself less productive with it when compared to VSCode - however VSCode is bloated, slow, uses a lot of RAM, and SSH functionality is unreliable.
I actually started writing this as a side project - using Rust, ratatui and a plugin system based on wasm (and dynamic C libs), but you know how side projects go
I had a similar experience. I liked nvim for simple editing, but not for anything multi-file. And then I found Helix, and I never looked back. I only hop into vscode if I want a Jupyter notebook.
I use Zed with SSH support daily, most often to SSH into a distrobox dev container running on localhost. It's a little jank but it works great for the most part.
Note that Zed has the aforementioned concern around downloading a remote binary as well. In my case this isn't an issue, since the distrobox container is not a security boundary of any kind.
I do my full-time development work using Neovide (a GUI frontend to nvim) over SSH. As a long-time vim user, this is great for me, but I will freely admit that it is nowhere near as easy to set up as VSCode, and it is also fundamentally a dumb client over SSH, so it suffers from lag spikes. There has been some discussion about what a smart client version of nvim would look like, but it's probably years out: https://github.com/neovim/neovim/issues/24690
I remember many years ago looking into mouse events over terminal and in that time you could only handle clicks, you couldn't track cursor position so dragging would be impossible. So I was curious to hear about someone actually making a usable mouse UI in a terminal.
As I do some googling it seems like there is now better support for that.
Kakoune has network-transparency - you can run the editor server on a remote system and run editor clients locally, communicating only via Unix socket.
Reminds me of Jenkins (the CI system) remote agent.
One would expect a remote agent with well-defined capabilities: read/write/delete files and directories; run the process with stdout/stderr capture; stop the running process started in previous item.
Instead, there is a generic bytecode executor, and Jenkins controller ships out Java bytecode to be executed remotely. Crazy stuff.
Task runners have to interpret the tasks one way or the other. Speaking of crazy stuff, Ansible in general ships out Python scripts to be executed remotely.
Is the news here that someone bolted an LLM onto that? Extensions always had this degree of access. npm or pip install can also do some pretty nasty stuff with a malicious package.
VSCode is an IDE designed to suffocate the open source alternatives, so that they retain full strategic control. Oh, and it also promotes their tech (Copilot, Github, C#, TypeScript). It's a long list of issues.
It works well though, particularly over SSH and devcontainers, although it has severe bugs that they refuse to fix, and it isn't open source so you can't fix it yourself.
I wish software was secure by design, like browsers are.
But it just isn't a business priority, because consumers have so little to lose.
And enterprise customers have strict environments, separate staging/production environments that reduce blast radius, and so on, so the insecurity is tolerable. Besides, employees can't be trusted anyway, so what's the point of having a very secure IDE if they immediately run curl|sudo bash.
Are there any good web-based alternatives? (like Runpod's openvscode-server)
Eclipse theia. It is an almost pixel-perfect ripoff of VS Code that integrates the open source components such as Monaco. It is what you are using if you've ever started a Google Cloud Shell Editor.
Amazing that most commenters seem to even be unaware of Eclipse Theia which is basically THE open-source VSCode. They need better marketing (well, being open-source, they'll never have great marketing like MSFT, of course).
I would add: ...and being Eclipse they will have no marketing at all. Eclipse offers tons of interesting IDE's, languages ranging from C, Java, PHP, there used to be Haskell support as well. Granted, not every language has the same depth of features, and some plugins are practically abandoned. There are tools for the automotive industry, tools for building Dsl's and IDEs, hardware programming, the list goes on.
Eclipse is built as an IDE, but also as a platform to build your own IDE. I think that DBeaver is also based on Eclipse-the-platform.
But eclipse also reinforces memes, look at eclipse.org
- Software from the US: Great marketing, invasive, beginner friendly, attention to UX, great design, steals your data by default.
- Software from the EU: Deeply buried on a 2007 website, great feature depth, interface tailored to power users, designers have been killed, community equals you + 20 experts on some mailing list, no data sharing or only as opt-in
After decades of using IDE's from Think Pascal/C, MCL, Borland C++/JBuilder and lots of Visual Studio and mostly PyCharm these days, I was forced to use an Eclipse IDE for a model driven dev project a few years ago.
Worst IDE experience ever and this tainted the 'Eclipse' brand for me forever.
and everything just worked, though the directions on that page look complicated, so it might be the wrong project. It was in the store that ships with the open source build and was definitely open source.
Other companies don't say EEE (MS also doesn't anymore, as far as I know), but that doesn't mean they are any better. In fact, I would say that Apple is far more guilty of doing this than MS is these days. But even so, what is the alternative? If MS creates any good product, people will accuse them of being at some phase in EEE, which is unfalsifiable.
I guess the alternative would be for MS to make this great product fully FOSS, so that there wouldn’t be a problem in the first place. But ofc that isn’t realistic for a plethora of reasons.
Also not saying that MS is somehow unique or worse than Apple, or Google or whatever, they each have their good and bad bits.
It's Microsoft's actions which lose them trust, regardless of what they might state in official communications.
Actions like the C# dev kit license footgun/rug pull, the closed source remote development extensions, and training copilot on GPL while pretending that you own any code it generates.
You don't need even need a rant on the Windows team, it would be beating a dead horse.
C# dev kit is completely optional. The debugger, language server integration and all the other features that you'd expect ship with the base C# extension.
> VSCode is an IDE designed to suffocate the open source alternatives, so that they retain full strategic control
What open source alternatives? Atom was a mess that kept breaking. LSP plugins are now used in almost every featureful editor and have really made editing a lot better. You spent more time configuring Vim and Emacs than they saved you. Microsoft made a really good code editor that set a standard and likely took market share from their own (mostly Windows) Visual Studio.
I do not use it anymore because of the creep of closed source plugins (+ they keep breaking my workflow) but I still think it is a great improvement.
> I wish software was secure by design, like browsers are.
Someone does not remember (or was not around) for the ActiveX or Flash days.
> You spent more time configuring Vim and Emacs than they saved you
I trade whatever default workflow that VSCode and other IDEs are imposing for a better editing experience. And even the initial time investment is short these days due to the trove of config and tutorials online.
After learning Vim, I ditched the files explorer and embrace the buffer workflow instead. Opening many windows at the same time to peek at multiple files, then switching to a new tab only if I don’t want to lose the current windows configuration. Then fuzzy searching for navigation, and using the quickfix list for search and errors. No friction from thought to action.
Another plus for me. I have an emacs session opened for weeks now inside a VM on my desktop to work on a side project. Whatever the computer (laptops or said desktopj, it’s a quick ssh, then resuming the dtach sessiom and my workspace is ready. Multiple files opened (almost all of them), a postgresql REPL, Tasks runners, and a lot of packages (magit, project.el, consult,…) working together to streamline working on code.
> I trade whatever default workflow that VSCode and other IDEs are imposing for a better editing experience. And even the initial time investment is short these days due to the trove of config and tutorials online.
You can configure VSCode with plugins. They aren't imposing any more defaults than vim or emacs do.
As VSCode is good enough, there is no oxygen for an open source effort to reinvent that wheel. At some point it will stale long enough that some bigger communities will want to tackle the challenge, but that won't be tomorrow.
I see VSCode as a net positive, but I think it's healthy to keep in mind the embrance->extend bigger picture.
Thirty years, two CEOs, and at least two industry redefining tidal waves ago. The people who trot out Microsoft's HTML 2.0 strategy as a reason their work 30 years later is a trap, are deep in tin foil hat land and jumping at shadows.
Look at their wall street filings for the last decade. If Microsoft is running an elaborate EEE with their open source work, that first "embrace, extend" phase is now 10+ years in and responsible for an enormous portion of their bottom line with the fastest growth rates anywhere in the company. "Extinguish" would be suicidal.
One has to wonder if these same people also think Apple still secretly doubts the "think different" vision that Steve Jobs introduced in the same time frame, and could revert to beige boxes at any time. Or that IBM is really a hardware company and will drop services any moment.
However, "hard to connect" with Microsoft, is not the case. When it came from their own notes. It's also not hard to connect IBM with the Fuhrer, but that's also in the past. Doesn't mean it never happened, though.
VSCode is part of their Embrace Extend Extinguish strategy.
It embraced open standards.
Then extended them with proprietary plugins.
And then extinguished alternatives by making their plugins incompatible.
Why did they buy GitHub?
Well, it turns out to be massively relevant for AI.
VSCode is well integrated with not just GitHub, but also Copilot, and Devcontainers, all of which strengthen their proprietary grip.
But GitHub provides free hosting? And offers freemium GitHub Actions.
Open source software uses these free solutions, but in doing so make their technology mainstream, to an extent where even suggesting alternative is thought ridiculous, "just use github actions bro".
Speaking of tin foil hats, the CICD pipelines could make it possible to selectively infect binaries at the distribution level, which is virtually impossible to detect, especially if the signing keys are part of the pipeline, which I assume is almost everyone. This is critical militarily.
Cloudflare is another example of a militarily interesting freemium strategy, where a vast number of businesses have allowed a man-in-the-middle, which practically defeats TLS encryption, allowing surveillance. And, selectively and virtually impossible to prove, could hijack your cookies, and gain access to all kinds of things. And infect the binaries you download.
Which is to say that EEE strategy is extremely powerful and effective. Otherwise, why would companies surrender the security of their users so readily?
"Extinguish" is about their competition, not the extended product/field. They will always invest to embrace and extend, that's the condition to outpace and cut off the competitors.
It’s not. Its core is open source, but the actual build that is branded VS Code and that people download is not. I’m not even referring to many of the key extensions that many people use, such as the SSH remote and Pylance, which themselves are proprietary.
If you want to use only open source code, you need a rebuild like VSCodium.
What are we actually talking about here?
VS Code is open source, the existence of a de-microsofted alternative, that's actually just as capable (VS Codium) is just confirming this.
> there is no oxygen for an open source effort to reinvent that wheel.
Also, VS Code is just a great product. I mean, why is it a bad thing? It's not like Micrsoft is exerting as much negative control if at all on the whole ecosystem like Google did with Chrome. What I can see is that the dev's are keeping a good and healthy relationship to the users. While I see that this can change arbitrarily, given that it's Microsoft, right now you have (or at least I do) give them the benefit of the doubt.
Many important plugins are only in the official marketplace, and it's not allowed to use this marketplace from open source builds.
The practical effect is that open builds like VSCodium don't have access to things like the C# plugin, making them not useless, but much less viable than actual VS Code.
C# has a fork of the official plugin which uses NetCodeDbg by Samsung. And the language server itself is a part of the SDK anyway. It works in VSCodium without any additional effort required.
I didn't know that it isn't allowed?
VS Codium even endorses downloading the files from there and installing them in Codium. Is this against their TOS or something?
> I see VSCode as a net positive, but I think it's healthy to keep in mind the embrance->extend bigger picture.
It is a terrible point. Emacs and vim have been around for 'how' long and they are still niche and difficult to use.
VSCode made it better, especially with LSPs. Make all the terrible arguments you want. Still does not change that before more people used the Windows only VS Studio and now they can use the (mostly free) VSCode on Linux. Whatever attempt Microsoft is making to embrace Linux to prevent a possible dev shift they are still cannibalizing their VS Studio sales to do so and Vim/Emacs still does not offer a good response to Code.
Another happy doom user (and formerly unhappy vim configure-er).
Although the objection I see is more like "Why bother learning to use emacs/vim when VSCode is free and does everything I care about and my friends use it?" Which, to be fair, the emacs/vim learning curve isn't for everyone. I sometimes wish they had less "leet programmer" cred, though, since what is cred to the leet programmer is (in this case at least) stigma to the majority.
I want to like/use Doom (also to be able to recommend it to to new-comers), and it neatly solves many "beginner issues", but I can never get it to do code-folding like in my own emacs-config.
Specifically, I'd want these 3 types of folding in the same buffer:
- "Chapter & Block-based", like in `org-mode`
- "Arbitrary lines folded", like in `vimish-fold`
- "Semantic folding, any level", like in `hideshow`
(Un-)folding should always be done with TAB, only for folding vimish-style, initial visual selection is needed.
When doing that in DOOM, I always end up with visual corruption, when some of fancier default eye-candy is switched on and then I use several types of fold in the same document.
I think, I saw code-comments, that there is an all-encompassing folding function in the works, but not yet finalized/activated. Hmm, maybe I should give it another spin, last time was 5ish months ago.
And on Mac, it just does the wrong thing for most shortcuts (the basic moving ones, like Option-Left/Right, which work on any Mac app, including browsers, but not on Kate), which is a huge shame because otherwise it's a very good editor.
That is "does not work" for most people, including on HN. Nobody should be expected to spend half an hour installing vidual studio and building a project before they can start to use an IDE.
So why not fix that? You can absolutely build a binary and release it and save thousands of people that effort.
Comments like this remind me of people who complain about an error they saw on Wikipedia: "So, you're going to fix that, right?"
If you have a pain point in OSS that you care about, you can fix that. Yes, you the person reading these words right now. That's the entire point of OSS.
I could, but nobody is going to trust my binary. And they shouldn't.
The build should come from the official maintainer. Period.
And participating in open source? Oh, I can assure you I am a seasoned open source contributor, but I am not going to just contribute to a random project. Wasted too much time on issues and pull requests that nobody looked at.
Easy to criticize other people, right? What have you done?
So help the official maintainer. Become the official maintainer of the Windows build.
If you don't want to, or can't be bothered with the time commitment, that's fine, but realise that every time you complain about an OSS project's failings, you're really complaining about your own inability to contribute, not their's.
If Zed wants to treat Windows as a second class citizen, I don't want to change their mind. I am sure plenty of people other than me are willing to help and have the ability to contribute. The fact that there is no official build for Windows for so long says plenty about the project. The writing is on the wall.
I am not an idiot. Recent developments in the open source world should already give everybody a better idea of where they should spend their time and energy.
You're taking offence where none was intended. I was not referring to competence, as I have no means to judge, your inability was a reference to your decision to not to contribute for whatever reason you have chosen.
You've made clear that you are not going to do this. Fine. My point is that this failing you perceive then, is about your decision/inability/choice/forced situation/whatever you want to call it, to not fix it, not theirs.
If you're anywhere near as experienced as you state you are at maintaining OSS projects, you'll know the issue I'm referring to here: entitled armchair quarterbacks telling maintainers what they "should" be doing, but not doing anything to contribute themselves.
Your original remark was that kind of entitled snide, back-handed, snarky comment that deflates OSS maintainers every day.
Engage with it, or accept that's where it is. Don't race around pointing out all the things it doesn't do that you want, that you're not prepared to make happen. You could offer time, you could offer actual hard cash, you could just move on and decide not to care.
That's my point. If you have maintained OSS, you know that's the point, I even contextualised it with an easy to understand metaphor in the form of "broken things" on Wikipedia that literally take seconds to fix.
If you didn't get that on the first or second pass, perhaps you're not quite the experienced maintainer you claim to be, in which case, just hold off criticising for a beat next time, and think about what you could actually do, and if it's nothing that's fine. Move on.
Doom kept breaking, spacemacs is just kinda annoying, and I don’t wanna go through doing my own from scratch again. I basically only use emacs for my couple literate configs because I haven’t found an equal alternative
That’s why I’ve been checking out zed/helix/kakoune lately. Zed to replace VSCode which feels bloated and the other two to replace vim. The keybindings are more intuitive to me and having auto complete of commands out of the box with a full menu showing shortcuts saved me a lot of frustration from day 0
> Someone does not remember (or was not around) for the ActiveX or Flash days.
"Hey wouldn't it be handy if every webpage can download binary code and run it? Oh and let it talk to every DLL in the system as well. Super handy! What could go wrong?" - Microsoft in 1998 :)
I mean sure we were all a bit naive in the 90s and 00s but did they really not see that coming?
> You spent more time configuring Vim and Emacs than they saved you.
Uh? I‘ve always used vim out of the box, and Emacs I got it just like I like by searching the .emacs file of a youtuber who has a configuration I likes. Exactly 1 minute.
> I wish software was secure by design, like browsers are.
I feel this is one of those "repeat it until it is true" marketing things, like "apple believes privacy is a fundamental right"
But really, I think vscode, browsers and apple products only tangentially secure because business goals, features and convenience trump these kinds of broad statements.
I so wish it was otherwise. There are so few islands of common sense in our world and the water level keeps rising.
I think it's more a case that browsers take security into account at the feature design phase, whereas other applications don't. That's actually a huge step in the right direction. Same thing with mobile OSes, which have a very preferable decision to sandbox individual applications, instead of running them with full user permissions & full user data access, like desktop OSes do.
Now, whether the browsers or mobile OSes actually are secure because of that, is a separate thing, but those are good steps to take.
> which have a very preferable decision to sandbox individual applications, instead of running them with full user permissions
It's great that they took security into account during the design phase. I wish they had also taken into account user empowerment. They sandboxed all the apps and in so doing made interoperation, plugins, patches, mods, etc basically impossible. Now the most widely-used form of personal computer is more like a portal to digital services than it is a computing platform. It's sad to see, and I refuse to believe that it's one-or-the-other when it comes to security vs power.
Browsers weren't really secure by design until IE first introduced a browser sandbox sometime in the IE8 days and then Chromium came along and set the standard for sandboxing.
> what's the point of having a very secure IDE if they immediately run curl|sudo bash
Docker is a technology that downloads random unsigned tarballs from the Internet and runs them as root. Also it turns off your system firewall in the process, to make all this more "convenient".
Really we have much more low-hanging fruit to pick.
It’s a bummer that those aren’t the defaults, but it would directly make things less convenient and therefore make people less likely to use it (same reason why installing various software is still offered as a Bash script that you curl and pipe to your terminal, e.g. Ollama; at least it’s not offered as the only way usually), what a world.
I hate to break it to you but that's a large percentage of open source projects. The high majority of code is by a low minority of people
I think this is because the barrier to meaningfully contribute is too high simply because large code bases are almost always complicated and hard to understand.
There's a few extraordinary exceptions (NetBSD source comes to mind) but they're extreme outliers
The first two are forks that fundamentally did not change all that much, the latter aims to create a "true" opensource alternative of VSCode (including the ecosystem, where VSCodium falls flat) to serve as a common base for (and by) a few industry giants to build their next-gen of IDEs on top of (an "IDE framework", per their description).
As for the first two, last I checked openvscode-server was just enough to host VSCode for the browser, code-server had a few extras, like hosting at a subpath.
> It works well though, particularly over SSH and devcontainers, although it has severe bugs that they refuse to fix, and it isn't open source so you can't fix it yourself.
VS Code dev here. Would you like to share that list of severe bugs? Also, can you clarify what exactly isn't open-source in the entire VS Code with SSH and devcontainers flow? It's disheartening to read this, knowing that this simply isn't true.
Where is the Remote SSH extension code? I always thought that was closed source?
Edit: The reason I think it is closed source is because a StackOverflow answer says so[1]. I’d be very interested in seeing the code if you could link to its repo!
The remote development extensions don't appear to be open-source. The marketplace page for the "Remote - SSH" extension will point you to a license that says, among other things, "You may not: work around any technical limitations in the software;".
The same page brings you to a github repo for the extension that contains no source code; it claims to be for gathering feedback only.
I don't know how you can imply everything about this is open source, maybe I'm not looking in the right place?
This is what posting sleep deprived gets you. I was referring to the cli[0] and server[1] components, which have most of the meat. Sorry for the misunderstanding. That being said, I'd love to know which severe bugs disrupt your usage.
Embrace, extend and extinguish.
Tell everyone that it is ok to use this crap because it is open source, despite our being impossible to have the exact same fully featured vscode built from source.
Not OP, but I've been trying to get remote development working for years but to no avail. The official response on the GitHub issue [0] in 2019 was:
> The "remote" functionality (SSH/WSL/Docker) is currently only available for VS Code proper, not 3rd party builds.
> [...] /cc @joaomoreno
Last time I checked, Arch Linux users who have the Arch Linux build of VS Code installed still cannot use remote SSH development nor dev containers. I definitely can't get it working on my own development machines.
Speaking of "disheartening": your fellow devs who wrote the Pylance extension decided to mount a ReDoS attack against anyone who opens it in a debugger. I merely tried to investigate an issue that I had. [0] [1]
Being on the receiving end of a deliberate ReDOS attack feels more than disheartening. This is not shedding a good light on the VS Code development team as a whole. This is a despicable act.
No idea. All I know is whenever I try to execute the module in e.g. VS Code's debugger, it somehow triggers the attack and enters a de-facto-endless 100%-CPU-load loop.
> I wish software was secure by design, like browsers are.
I don't. Browsers are already close to "security or utility, pick one"[0] if you try to go beyond the TV + form filling appliance experience. I don't want this kind of thinking to leak out to all software I use. Like, I'm happy to be able to write:
find . -type f [stuff] -exec rg 'foobar' {} +
without worrying about rg (or anything) refusing to run because its vendor didn't set up Access-Control-Allow-Origin header correctly, or similar such bullshit that's just commonplace whenever you try to operate (instead of consuming) or integrate anything on the web. And no, I don't want to have to buy a domain and publicly spell out my computers and get them legit certificates just so they're allowed to talk with each other when physically next to each other and on the same LAN.
I don't want my OS to start looking like Android either, where everything is hidden and nothing is allowed to talk to anything else - i.e. literally the opposite of the promise Android started with.
--
[0] - Security and usefulness are fundamentally opposing forces. In the limit, the most secure computer system is a dead rock.
First time I see someone criticize Access-Control-Allow-Origin. You do realize it prevented countless script injection attacks from affecting users? Most of whom are not people who are on the web for the purposes of hacking random integrations.
Also seems like your idea of integration is using someone else's server without permission.
> First time I see someone criticize Access-Control-Allow-Origin.
From the POV of API integrations it's basically annoyance. It doesn't prevent or discourage using an endpoint from scripts and applications except browsers, which voluntarily handle it and also don't give the end-user any control over it.
> You do realize it prevented countless script injection attacks from affecting users?
I do. We're talking about making software as secure as web browsers. I can begrudgingly accept that the World Wide Web is what it is because it is World Wide, but I don't want any of this bullshit to spill over to general-purpose personal computers. It's bad enough that we increasingly do most of our computing in the browsers.
> Also seems like your idea of integration is using someone else's server without permission.
Not server but software, and the very phrasing of it is... I don't know where to even begin addressing it.
I am not and am never gonna ask permission to use software for whatever purpose I want. That's, like, the basic philosophy of computing. Integrations - voluntary or not - are basically an extension of that. Adversarial interoperability is a sad necessity today, but we're not even talking about that - we're talking transplanting "browser security" like CORS to places and use cases where it would be mostly annoying, leaving users at the mercy of the software provider to kindly relax the security flag a bit.
Android has very good reason to have such strict process isolation. For example, that third party calculator app I downloaded shouldn't be able to interface with my bank app. That said, I do feel it (Google) has used security as an excuse to build a walled garden.
That's a lot of accusations without evidence. VSCode does questionable things, but nowhere near the levels you are describing.
And is there any evidence that VSCode is not secure, by Node.js standard? Has there been significant security incidents that were not handled properly? Has VSCode been neglecting security issues?
No to all those questions, based on my experience. Node.js inherently is loose on permissions -- by default you can do IO/connect to Internet however you want -- but that's not VSCode's fault. Otherwise, VSCode team has been very responsive at handling security issues.
(Saying this as an experienced VSCode user and extension developer.)
Cool theory but no one uses typescript, github or C# because of VSCode. It's a nonsensical narative if you just spend more than a few seconds thinking about it. All those things dominated their niche before VSCode came into the picture.
Any better product can be accused of "trying to suffocate the OSS alternatives". Do Microsoft somehow have the power to make other OSS projects suck?
Other than not being the exact way the author would have done things, what's the issue? If you're afraid your editor will go wild — and this is a possibility for any editor — you should setup your development environment in some type of sandbox. Personally, I host mine in a multipass virtual machine.
This is an actual issue can someone write a rust replacement for whatever VSCode is doing and also making sure this works on the open source version (VSCodium) thanks
Agreed, because VSCode does not provide an SSH Agent but does communicate with your local one (their own version of ForwardAgent, complete with the security implications that carries). And the way it does that breaks a popular macOS SSH agent: https://github.com/maxgoedjen/secretive/issues/543
Oh shoot, secretive is one of the few ways I knew of to keep track of each time an SSH key was actually used to auth something. I love using Agent Forwarding but the idea of anybody with root being able to arbitrarily auth stuff gave me a (perhaps unreasonable) feeling of insecurity.
I don't know what the alternative would be here. VSCode's SSH edit works surprisingly well, and I stopped fiddling with vim, nano, or micro on my remote machines long ago.
The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book.
This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.
Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.
That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter.
VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]:
>If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases.
Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.
> Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.
Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.
I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?
One fewer tool to think about. It remembers the connections and instantly gives you access to a full-fledged editor on a remote server. It just works, and I don’t think about it twice, which is a huge win in my book. I’m good with the trade-offs.
It’s still not quite the same thing because it feels like you’re literally sitting at the remote machine; the code completion is there using an LSP that doesn’t have to pay a network cost, executables run locally which means you can be on a local Windows and remote Linux or vice-versa, and all in a super easy to use package that auto-restores the session whenever you come back even if you’ve put the machine to sleep.
By comparison, I’d say doing things over sshfs and terminals is the fiddling part.
Why is that? How much data are we expecting the LSP to ingest?
For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.
That doesn't work if the remote is a different platform or architecture. Also, part of the point of running remotely is to do compute on the remote (often a powerful workstation or server), not locally.
You can use sshfs if you like. But there are many use cases where you have to do things remotely.
For languages like Rust, the language server does compilations — it has to run on the remote because it has to know about OS/arch-specific details.
There's a bit of latency between when you type and when the language server shows or hides the squigglies. But it's less than the time it takes to compile stuff anyway.
Absolutely. It worked fine before vscode existed and it will work fine when the next hot button IDE comes along. I'm not sure why people keep reinventing the wheel and creating themselves new problems!
The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".
Persistence is important to me, and making it read-only significantly reduces its usefulness. I regularly SSH into a dev machine to run scripts and update configurations. As long as a tool lets me do that without getting in my way, I'm good with any solution that works.
Then tramp would be a perfect fit for you as long as you’re willing to learn emacs. If you open a remote file, almost all actions when that buffer is selected will execute in the remote context (launching commands, visiting directories, opening a shell,…)
You don't know what you're missing then and I'm not sure such opinions count. It's probably for the best to refrain from criticizing things one has no experience in.
Not wanting to pick up a tool isn't criticism. I just said that I couldn't care less. It's an editor. I work mostly with VSCode and a sometimes with Goland or Intellij and don't think about them too often. Editor wars are lame and old; so are linter and formatting wars.
Tramp is perfectly able to write, it's just that it does it by writing a temp file locally and then using ssh to transfer the file to the remote, rather than installing a copy of itself on the remote and acting through that. It only uses executables that it finds on the remote. So if make and gcc and sed and such are available it's basically transparent, indistinguishable from local editing except for network round trips, and the only changes it leaves behind are the files you edit.
When you’re in a buffer displaying a remote file, most commands take that in account and execute in the remote context. And more often than not, that means connecting through pipes (and files) inside the ssh tunnels. Eglot (with gopls) works fine and fast for me. Executing ‘shell’ opens a remote shell, as well as launching tasks through compilation mode. Grepping and finding files, as well as dired also work fine.
From what I’ve seen, my colleagues using vscode are hampered in ways they don’t recognize because they have no concept of how good things could be. Working with multiple remotes, they’re often completely unaware of which one they’re connected to or what state their connection is in. Their terminals are laggy and session state persistence is inconsistent. It’s just a massively worse experience than tmux + a real text editor. Plus the server is a real pig and they often end up running half a dozen server instances because the server doesn’t terminate properly. And then, half the updates break and they lose an hour because they don’t know how to ssh into the host with a real ssh client and clean up the busted vscode server.
This is what makes VSCode's remoting features awesome. This is the right architecture. Parts of the editor should run on the client and other parts on the server.
> The underlying protocol on that connection can: Wander around the filesystem, Edit arbitrary files, Launch its own shell PTY processes, Persist itself
I was wondering about this too. Once you have SSH access, unless your user is restricted, you can do whatever in the remote system.
All VSCode is doing here is installing node to run the extensions, setting up a WSS connection back the client for realtime communication. I don't see the harm there given the extensive feature set.
One can ssh into untrusted remote host with little risk for local machine security. That is, if the remote site is compromised one cannot use it general to compromise the local machine. At best the attacker can try to exploit bugs in terminal escape sequence handlings or rendering of complex Unicode characters by the local terminal. This is a relatively small attack surface.
With vscode that exposes the local machine to the remote with support of very complex and undocumented protocol it is entirely different story.
Which is a pity especially given that VScode is browser-based and browsers are designed to allow connections to untrusted servers.
I suppose it will be a different story if VScode was designed with remote editing capabilities and treated the local stuff not different from remote. But given that the ssh extension was brought as an after thought with little regards for the local security we have the present unfortunate situation.
It's the other way around: the post is saying that the remote VSCode agent can tell the client to just do whatever. That's not how SSH usually works, if an SSH server can pwn a client that's a bug.
I think it's only necessary because extensions may need to run client side. Not sure if that means the extension needs to be published on their marketplace site.
This is going to sound naive but, I don't understand what the security issue is. If you can ssh into a machine and port forward a socket, you already have permission to do all the other things. VSCode's protocol seems to be exposing it in way that's more convenient for them.
How is this a security problem? Is it because someone on the same network as the remote machine but without SSH access can connect the port that is forwarded over SSH?
As a user, I quite like how well VSCode's SSH system works.
I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty.
VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.
Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.
Is it better to programmatically interact with bash to provide the features VSCode does? Do note that I am unwilling to accept an implementation with less features/ease of use!
I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.
Bash is not running though. You might get a Bash session once you connect via SSH, but it just sits there waiting for you to input commands, while the VS Code installed agent thing does network stuff on its own iiuc. Bash is not acting as a server, afaik.
> However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.
I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?
Because if the Agent code is compromised, the fact that it leaves things behind is enough for an attacker to hide whatever they need along with the vs code blob. Vscode does this for the right reason, mostly it’s so the bulk of it runs on the host where you’re doing remote development or WSL or whatever. But like a lot of dev stuff these days, compromise the npm packages and bingo you can own all the machines.
Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.
The argument is that you're running code on the remote host, and it could be compromised. The same argument can be made about any code you run on the remote.
VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.
A user that can manage remote processes is generally going to have pretty high permissions.
For example, opening up debug ports on the running server processes, sudo privileges, or just the ability to run arbitrary code or curl in random binaries from the internet.
We usually don't hand over full ssh sessions to third party programs, so while you're right, I think people are not used to this level of trust into an app.
The article was to me a good reminder that it's a whole other level of access than just remote mounting a file system.
This is really big. I always thought Vscode ssh capability was just some black magic that the open source community wasn't able to replicat well with vscodium extensions. Yet, it seems the reason why is that MS threw a curve ball with that naming.
I think the latest Jetbrains tools do the same or similar things. They also install their own server on the target machine and connect to that. And I mean it's Jetbrains, so again, closed source tools. But it's not Microsoft so nobody is talking about it I guess.
If you're thinking about JetBrains' remote development, it's actually the IDE (a headless version) that's installed on the remote dev machine. Since you first need to install the IDE on the dev server first, you are never under any illusion that it's a simple SSH-based remote editing à la vim (even though it also relies on SSH).
I think you are talking about https://www.jetbrains.com/remote-development/gateway/ which requires a separate manual install on the client followed by a manual installation on the server during setup. It is not part of the regular IntelliJ IDE as far as I can see.
It isn’t. I mean yeah gateway is what you described. But the functionality is also included in Jetbrains IDEs and doesn’t require any manual install on the server. It installs its own thing exactly like VSCode does.
I can't find any such thing in PhpStorm v2024.3, can you tell me the feature name? Is it this you are thinking of (which requires some clear manual steps)?
...which I've come to expect from Microsoft. Windows scrozzles the efi partition for my other OS every third or fourth time it installs updates. It's like they think they own every computer they have code on.
They do think they own every computer they have code on. This is modern computing. Your hardware is an extension of "the cloud", if you let MS, apple, or any other big co into it.
But the author doesn’t give a single example, and so there’s nothing someone else can do to explain why or continue the conversation. The best we got use that he has a vague sense of unease, which I don’t think is very useful.
> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:
- Wander around the filesystem
- Edit arbitrary files
- Launch its own shell PTY processes
- Persist itself
When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.
I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/
Containers on MacOS are ran inside a Linux VM. If you ensure that the Linux VM doesn't have access to anything besides the required files/networks, that should be pretty secure.
Best case you go through the settings of Docker, Podman or whatever you use to limit integrations. Then, from within the VM and container see what networks, files, etc. you can reach to be sure.
I think in context the challenge here is to use remote editing to treat the container as a VSCode remote. As shown, that's not enough of a sandbox because the agent gives a route out.
I've attempted to use the sandbox-exec utility, but didn't have the stamina to get a working sandbox file written.
In general, I'd like to be able to sandbox more things. I'm using the app store version of slack because slack doesn't really need access to all of my files.
Usually it should also not be problem with -X because then the client is not trusted (but some distributions change the defaults here because some clients then don't work properly! unfortunately, there is not much interest in fixing this since two decades because X is dead anyway or so)
I've never seen any distributions enable ForwardX11Trusted by default. Do you have any examples? It seems very unlikely to me that a distribution would do this for a relatively niche use case.
If I have X11 forwarding on, what can Evil apps do? Launch UI for sure. Screenshots? I imagine so. What else? Send keyboard events, which would be game over?
They can only do those things if the X11 security extension restrictions are disabled with ForwardX11Trusted=yes or by using -Y rather than -X. This has been the case for the past 20 years.
It's helpful for evading detection, because if you've compromised a machine, you can drop in the server binary and it'll have been added to the allowlist for devs to run.
One reason it's a problem is because it's very unexpected behavior. Software should follow some sort of pattern that you can develop a reasonable mental model around.
> If you can ssh into a machine and port forward a socket, you already have permission to do all the other things.
Only technically. There are lots of situations where people (or robotic alarm bells) will be miffed if you instal your custom sw stacks, remote shells, "i don't know what these binaries are" etc on some servers you're supposedly just editing config files on.
There are lots of situations where people will not notice at all. At my last gig, I wrote pretty extensive Ansible manifests that built and configured all my favorite tools on on bog-standard company provided development hosts so I found them cozy for remote work. I took severe liberties with these hosts and nobody batted an eye.
Yeah, this is just being sensible. There at most you might lack some approval for your solid engineering decision. But when the described kind of worming in happens without your knowledge and there's just some random reverse shell stuff appearing out of nowhere, nobody has looked the sw through it to see if it's secure, what's the supply chain, etc, it's different.
You're already trusting that third party agent on your own computer. If VSCode itself was malware then it can do anything you can do, including sshing into remote machines and running commands behind your back.
Are you saying that the VSCode binaries are not built from the exact source that is available? Or that the opensource license doesn't apply to the version of VSC that is distributed via binaries?
I'm using VSCodium myself anyway, but I'm also installing it from binaries (precompiled packages), as is the case with most opensource software I use.
No -- when I ssh somewhere I am NOT giving them (the server) permission to run code on MY computer. When I vscode-remote somewhere then I AM giving them (the server) to run code on MY computer. You don't expect visiting a website to give the website permission to edit your local files, and so similarly some people might expect that if they are remote-editing with vscode they are not giving the remote-server permission to edit their local files either. Best to be aware!
I mean, yeah, technically true - although you would connect in untrusted mode if you didn't trust the machine where you were editing code. At that point it should only be slightly more dangerous than opening a web page from the remote server.
So yeah, if you don't trust the remote machine then I agree - you probably shouldn't use it. But I don't really think that's the use-case they had in mind.
I think you’re basically right: it’s not a security problem in that it doesn’t inherently traverse any vulnerabilities or security boundaries.
But it is a security problem in the same way that “curl | bash” is a security problem. An even closer equivalence might be something like “curl | bash” in your bashrc.
Detect AND change what is sent from the server. So you open the link in a browser and see that the remote shell code is fine, does what you want, then you `curl | bash` it and it sends a completely different program to run.
If you trust where you are curling from, and you trust everyone they trust and that they definitely haven't been hacked, then great! Blindly eval that code! That's what I do :)
The threat model where a malicious server can trick curl|bash but not the alternatives is extremely narrow. Reacting to curl|bash is missing the forest for the single tree.
In my mind, it mostly is about curl|bash not being auditable. On the spectrum of [auditable to not-auditable], curl|bash is as far to the right as possible, with things like distro packages far to the left. Maybe for a specific piece of software that's okay, but I think we would readily agree that it'd be a problem for all components of an OS to use bash|curl.
Bear in mind that, like many bits of security advice, this is highly context-dependent. It may vary based on your risk tolerance, your level of trust in the vendor, how robust other parts of your infrastructure (e.g. threat monitoring tools, network segmentation, etc.) are.
It is not a security problem if you know what you are doing and trusting the source. As a general way of installing software is is problematic because it is a risk when careless users execute untrusted code from the internet. Using this in cases where it could be seen a safe encourages such unsafe behavior and undermines efforts to train users not to do this. There is also the issue that websites are generally less safe than dedicated infrastructure of distributions. Those also typically ensure some level of quality control and auditing.
If I want to run a software written by someone, going to that someone's site and grabbing the source and/or binary straight from them seems like a pretty straight-forward decision, you don't need some middle man of a "distribution maintainer".
Besides, while I appreciate the efforts of the distro package maintainers, they are overworked and can't really give the amount of care this huge pile of software in the repository needs, not to mention that sometimes their efforts are counterproductive (IIRC Debian used to deliberately break some terminfo(5) records to work around problems in some other packages). And I definitely remember reading an article (though I can't for the love of me to find it) about a Linux distro doing an automated switch from some sort of RPM-like packaging to straight-up using Flatpak, with predictably horrible results of lots and lots of broken software.
A piece of software that is ostensibly trying to help you is gathering information without your knowledge and.. one of these days may upload it to the mothership? That's kinda not ok don't you think?
I have been for like a month now noodling on a long-form post about a piece of software we've been noodling with for 3-4 years now. Kurt is freaking out, because we haven't written anything on the blog since, like August. Finally I'm like, look, I will write the simplest thing I can come up with. We'll do the opposite of what we've been doing. We'll do anti- effortposts. I bet I can do one in 30 minutes.
I promise, I thought about this less than you have. It's a thing we were tinkering with, and I wrote about it. That's all.
That first paragraph (in your HN comment, not the blog post) would have read better with zero periods.
Glad to see one of my favorite blogs is still active. I was starting to get a little worried.
The first two blogs currently listed, McCord-Valim’s FLAME-Livebook-GPU and your post which has the word “murid”, truly captures the psychological arc of a developer.
Thanks for the post. I see now that it's bananas, but I didn't quite get that from the blog post. You list the things this agent can do, but I immediately assumed it went in the other direction, because anything else would be bananas. The statement in the README put it more succinctly for me:
> A compromised remote could use the VS Code Remote connection to execute code on your local machine.
I feel like that "security note" should have a CVE number next to it.
It seems like ssh may be the problem. I feel like there should be a way to ask for a docker like experience when ssh ing. Tell it to use is specific APIs to prevent process or filesystem access outside a particular folder (possibly allowing system binaries, although that might complicate things and require vscode to push more stuff to client). Basic googling indicates some choot options in the ssh server but nothing is mentioned on 5he ssh client man page.
Although maybe the solution is to download a docker container on the remote (directly if it has access to dockehub or over an ssh connection if it doesn't) then run a docker container mounting the remote directory and connect to it over ssh.
The problem with only syncing files from the subdirectory is that you also want to be able to run &debug on the remote started by vscode. So plugins also need access to remote or to run remotely for some code observation that may be prohibitively expensive if run locally(pre sync of whole subdir)
If you’re ssh-ing as a normal user you should only be able to modify files in that users remote home directory. You don’t need all that docker stuff just stop using admin accounts for normal access.
> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.
Totally agree that using vscode remote on production servers is insane.
Everything else described as "bananas" sounds like expected functionality.
I think the use case is mostly dev servers, either remote machines running in the cloud or docker containers running locally. I don't use VSCode much, but the one thing I do use it for is when I need to do something linux-specific. I spin up a linux VM on my MacBook and use VSCode to remote into the VM.
All you need is a well-defined .devcontainer file.
Debugging, extensions, collaborative coding, dependant services, OS libraries, as much RAM as you need (as opposed to what you have), specific NodeJS Versions — all with a single click.
It's dev-environment-as-code and you can version control it.
VSCode’s entire security model is bananas. As far as I can tell:
The client and its scripts and plugins get unrestricted access to the remote system.
The code you’re editing (if not in restricted mode) gets full access to the system it’s on (which is IMO an unfortunate default but not surprising — it’s really time for development systems to wake up and sandbox the code being developed to at least be limited to its own directory tree, but that’s a different story).
The code you’re editing (if not in restricted mode) and remote plugins (no prompt at all AFAICT) get effectively full access to the client system, subject only to whatever privileges the client itself has. Yes, you read that right, if you Remote-SSH into a machine, that machine immediately owns you. Microsoft knows, and they do not care.
I mean if VSCode is wrong then Vim and Emacs are condemned to an eternity of hell. I think there's a culture of editors being powerful in this way to a fault, on purpose. I think that's why devs like them— the training wheels, guard rails, seatbelts are all off.
This is, frankly, absurd. I have literally never, in my entire time using VSCode with Remote-SSH, wanted the repository or an extension or anything at all in the whole IDE to have any sort of access to my client machine with the possible exception of reading my VSCode config. No files in my home directory, no network, no anything.
(Some people may like VSCode to forward a port to get a local web browser to target the remote machine. Fine, make that an option. I, personally, prefer to forward the port myself.)
If you don't trust your own dev VM, why do you use it for development? Why do you connect? If you clone any random repository and click "trust this" - what do you expect to happen?
The main thing would be supply-chain attacks designed to execute code on developer boxes. ideally, a dev VM or container that gets pwned wouldn't be able to immediately start exfiltrating all the secrets on your machine, just whichever ones you've given to the dev environment, which are probably fewer than "all of them."
I often connect to my remote servers because they have a problem. If a machine has a problem I can ssh into it and inspect it without worrying about my localhost. If I used vscode, I have to also be lucky, which is not a good security assumption.
If I want to edit code I don't trust, it would be entirely sensible to stick it on a throwaway VM and SSH to it. Except that VS Code entirely screws this up.
As far as I know, even if you don't tell it you trust the code, the mere act of SSHing to the system blows up the trust boundary, and malicious contents of ~/.vscode on the target machine can get RCE on the client machine.
And I want to connect because VSCode is a fairly nice editor and the actual Electron application works a bit better than the webpage version. But the Electron application can't bother to sandbox itself and doesn't have a security model, so there you go.
I wouldn't expect the remote daemon to have full access. Should be running under the associated user account. However, if installed with privileges (via sudo, etc) to persist long-term, well you get what you asked for.
Compromising your user account is pretty bad. Let's see:
- Often gets your SSH key. Certainly gets to use your SSH agent.
- Can easily persistently compromise your web browser.
- Can trivially exfiltrate all your data.
- Has a good chance of being able to run 'sudo'.
- Can generally break Mac OS's sandboxing. (There's no shortage of examples demonstration that Apple really doesn't try very hard to make Mac OS resist attack by programs that are sort-of-sandboxed.)
- Gets all of your privilges for all of your fancy cloud services: GitHub, your favorite cloud's admin page, your email, slack, etc.
Saying "but it wasn't root" is not much comfort, nor is it even necessarily true.
I forgot to mention that the client software does have access to your user account on the local machine as well. That's always been the case with just about all software. These days one must look into a local firewall and sandboxing for further protection.
> LLM-generated code is useful in the general case if you know what you’re doing. But it’s ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup).
Why not just run the agent locally to close the loop? I wrote an agentic coder just in the last week (open sourced it a few hours ago) that runs on the command line:
VS Code is written in JavaScript, it's inherently insecure. Now add an LLM that's familiar with JavaScript and it can easily escape and do arbitrary things. Where's the issue? Programming an IDE completely in JavaScript. It's like writing a text editor in English.
Why is JavaScript fundamentally insecure? What would be a secure language in your opinion? And how are the issues highlighted in the blogpost related to JavaScript?
VS Code has inherent security concerns due to the dynamic and unbounded nature of JavaScript combined with the attack surface introduced by its extensibility and web-based architecture. Electron (the JS interpreter used) has a dynamic web-based attack surface. Even if you mapped it out, it can change at any time thanks to the changing nature of JS standards.
Furthermore, the security issue with extensions in VS Code is well documented. And the obvious bit is it's executing code sometimes, arbitrary user code and extension code. Telementry, etc. are built in. It's really up to the user to use it in a secured manner. A lot of people just don't consider this.
As mentioned in other threads, I'd love it if I could use Sublime Text remotely, but am stuck using VSCode simply because of what this setup allows in terms of remote coding. Perhaps a standard too that any editor could use would be amazing -- is there anything else out there that enables this much functionality out there?
Former long-time Tramp user, now Zed for the most part + VSCode for a few things. I'll say that neither Tramp, nor running an editor directly on the remote, are nearly as usable on a high-latency connection as Zed or VSCode. I think that generally wins out over the security concerns for me.
521 comments
[ 3.1 ms ] story [ 223 ms ] threadA Node.js binary installation. A WebSocket connection back to the VSCode frontend. Extensive system access capabilities.
The VSCode agent has broad permissions including:
File system navigation. File editing capabilities. Shell PTY process creation. Self-persistence abilities.
The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?
Whether such a thing should ever be written is a completely different question, of course.
But if you find an exploit that will run by simply editing a file in emacs, you could put that file on the server and
That would, of course, be just as terrible an idea as when vscode does it.
Now imagine your host is a rented VM that you throw away after use.
I'm all for the former, but the latter is unnecessary.
Yikes.
https://github.com/zed-industries/zed/issues/12589
nvim showed me that it's possible, with mouse events, right-click context menus, and a rich editing experience. I did genuinely try to transition to nvim but I use my mouse a lot; resizing panels, using the file tree, copy/cut/pasting files in the file browser, tabs, etc.
That's not to say nvim is bad, but after hours of configuration, I personally found myself less productive with it when compared to VSCode - however VSCode is bloated, slow, uses a lot of RAM, and SSH functionality is unreliable.
I actually started writing this as a side project - using Rust, ratatui and a plugin system based on wasm (and dynamic C libs), but you know how side projects go
EDIT: https://helix-editor.com/
I love that the homepage has a video showing usage. Such a great way to demonstrate it.
I'll take a look again
Note that Zed has the aforementioned concern around downloading a remote binary as well. In my case this isn't an issue, since the distrobox container is not a security boundary of any kind.
As I do some googling it seems like there is now better support for that.
One would expect a remote agent with well-defined capabilities: read/write/delete files and directories; run the process with stdout/stderr capture; stop the running process started in previous item.
Instead, there is a generic bytecode executor, and Jenkins controller ships out Java bytecode to be executed remotely. Crazy stuff.
https://github.com/microsoft/vscode/issues/201129
Most people who hit this hard pinned their vscode to 1.85 & it took a while till this turned into a simple nag bar on top of their editor.
It works well though, particularly over SSH and devcontainers, although it has severe bugs that they refuse to fix, and it isn't open source so you can't fix it yourself.
I wish software was secure by design, like browsers are. But it just isn't a business priority, because consumers have so little to lose. And enterprise customers have strict environments, separate staging/production environments that reduce blast radius, and so on, so the insecurity is tolerable. Besides, employees can't be trusted anyway, so what's the point of having a very secure IDE if they immediately run curl|sudo bash.
Are there any good web-based alternatives? (like Runpod's openvscode-server)
Eclipse is built as an IDE, but also as a platform to build your own IDE. I think that DBeaver is also based on Eclipse-the-platform.
But eclipse also reinforces memes, look at eclipse.org
- Software from the US: Great marketing, invasive, beginner friendly, attention to UX, great design, steals your data by default.
- Software from the EU: Deeply buried on a 2007 website, great feature depth, interface tailored to power users, designers have been killed, community equals you + 20 experts on some mailing list, no data sharing or only as opt-in
(they are just memes, with a pinch of truth)
Worst IDE experience ever and this tainted the 'Eclipse' brand for me forever.
I thought I used this one:
https://github.com/xaberus/vscode-remote-oss
and everything just worked, though the directions on that page look complicated, so it might be the wrong project. It was in the store that ships with the open source build and was definitely open source.
Same reason why some people are adamantly against using closed source software though at least https://github.com/VSCodium/vscodium exists.
That said, personally I use OSes like Windows or IDEs like JetBrains sometimes just because they help me get things done, it is what it is.
Also not saying that MS is somehow unique or worse than Apple, or Google or whatever, they each have their good and bad bits.
Actions like the C# dev kit license footgun/rug pull, the closed source remote development extensions, and training copilot on GPL while pretending that you own any code it generates.
You don't need even need a rant on the Windows team, it would be beating a dead horse.
What open source alternatives? Atom was a mess that kept breaking. LSP plugins are now used in almost every featureful editor and have really made editing a lot better. You spent more time configuring Vim and Emacs than they saved you. Microsoft made a really good code editor that set a standard and likely took market share from their own (mostly Windows) Visual Studio.
I do not use it anymore because of the creep of closed source plugins (+ they keep breaking my workflow) but I still think it is a great improvement.
> I wish software was secure by design, like browsers are.
Someone does not remember (or was not around) for the ActiveX or Flash days.
I trade whatever default workflow that VSCode and other IDEs are imposing for a better editing experience. And even the initial time investment is short these days due to the trove of config and tutorials online.
After learning Vim, I ditched the files explorer and embrace the buffer workflow instead. Opening many windows at the same time to peek at multiple files, then switching to a new tab only if I don’t want to lose the current windows configuration. Then fuzzy searching for navigation, and using the quickfix list for search and errors. No friction from thought to action.
Another plus for me. I have an emacs session opened for weeks now inside a VM on my desktop to work on a side project. Whatever the computer (laptops or said desktopj, it’s a quick ssh, then resuming the dtach sessiom and my workspace is ready. Multiple files opened (almost all of them), a postgresql REPL, Tasks runners, and a lot of packages (magit, project.el, consult,…) working together to streamline working on code.
You can configure VSCode with plugins. They aren't imposing any more defaults than vim or emacs do.
This is part of parent's point IMHO.
As VSCode is good enough, there is no oxygen for an open source effort to reinvent that wheel. At some point it will stale long enough that some bigger communities will want to tackle the challenge, but that won't be tomorrow.
I see VSCode as a net positive, but I think it's healthy to keep in mind the embrance->extend bigger picture.
You people need to get a new catch phrase, hard to draw a connection between something MS created and "embrace, extend, extinguish"
Thirty years, two CEOs, and at least two industry redefining tidal waves ago. The people who trot out Microsoft's HTML 2.0 strategy as a reason their work 30 years later is a trap, are deep in tin foil hat land and jumping at shadows.
Look at their wall street filings for the last decade. If Microsoft is running an elaborate EEE with their open source work, that first "embrace, extend" phase is now 10+ years in and responsible for an enormous portion of their bottom line with the fastest growth rates anywhere in the company. "Extinguish" would be suicidal.
One has to wonder if these same people also think Apple still secretly doubts the "think different" vision that Steve Jobs introduced in the same time frame, and could revert to beige boxes at any time. Or that IBM is really a hardware company and will drop services any moment.
It embraced open standards. Then extended them with proprietary plugins. And then extinguished alternatives by making their plugins incompatible.
Why did they buy GitHub? Well, it turns out to be massively relevant for AI. VSCode is well integrated with not just GitHub, but also Copilot, and Devcontainers, all of which strengthen their proprietary grip.
But GitHub provides free hosting? And offers freemium GitHub Actions. Open source software uses these free solutions, but in doing so make their technology mainstream, to an extent where even suggesting alternative is thought ridiculous, "just use github actions bro".
Speaking of tin foil hats, the CICD pipelines could make it possible to selectively infect binaries at the distribution level, which is virtually impossible to detect, especially if the signing keys are part of the pipeline, which I assume is almost everyone. This is critical militarily.
Cloudflare is another example of a militarily interesting freemium strategy, where a vast number of businesses have allowed a man-in-the-middle, which practically defeats TLS encryption, allowing surveillance. And, selectively and virtually impossible to prove, could hijack your cookies, and gain access to all kinds of things. And infect the binaries you download.
Which is to say that EEE strategy is extremely powerful and effective. Otherwise, why would companies surrender the security of their users so readily?
Which open standards?
What software existed before VSCode that would somehow have been compatible with VSCode plugins if not for this imagined villainy?
> Apple
Is Apple thinking different ? I'm lost.
https://news.ycombinator.com/item?id=31718168
Unfortunately, we're not anywhere near "letting it go."
If you want to use only open source code, you need a rebuild like VSCodium.
> there is no oxygen for an open source effort to reinvent that wheel. Also, VS Code is just a great product. I mean, why is it a bad thing? It's not like Micrsoft is exerting as much negative control if at all on the whole ecosystem like Google did with Chrome. What I can see is that the dev's are keeping a good and healthy relationship to the users. While I see that this can change arbitrarily, given that it's Microsoft, right now you have (or at least I do) give them the benefit of the doubt.
The practical effect is that open builds like VSCodium don't have access to things like the C# plugin, making them not useless, but much less viable than actual VS Code.
> This is part of parent's point IMHO.
> I see VSCode as a net positive, but I think it's healthy to keep in mind the embrance->extend bigger picture.
It is a terrible point. Emacs and vim have been around for 'how' long and they are still niche and difficult to use.
VSCode made it better, especially with LSPs. Make all the terrible arguments you want. Still does not change that before more people used the Windows only VS Studio and now they can use the (mostly free) VSCode on Linux. Whatever attempt Microsoft is making to embrace Linux to prevent a possible dev shift they are still cannibalizing their VS Studio sales to do so and Vim/Emacs still does not offer a good response to Code.
Doom emacs + Evil is basically free in terms of config time and it’s wonderful.
Although the objection I see is more like "Why bother learning to use emacs/vim when VSCode is free and does everything I care about and my friends use it?" Which, to be fair, the emacs/vim learning curve isn't for everyone. I sometimes wish they had less "leet programmer" cred, though, since what is cred to the leet programmer is (in this case at least) stigma to the majority.
Specifically, I'd want these 3 types of folding in the same buffer:
- "Chapter & Block-based", like in `org-mode` - "Arbitrary lines folded", like in `vimish-fold` - "Semantic folding, any level", like in `hideshow`
(Un-)folding should always be done with TAB, only for folding vimish-style, initial visual selection is needed.
When doing that in DOOM, I always end up with visual corruption, when some of fancier default eye-candy is switched on and then I use several types of fold in the same document.
I think, I saw code-comments, that there is an all-encompassing folding function in the works, but not yet finalized/activated. Hmm, maybe I should give it another spin, last time was 5ish months ago.
Me? Nope.
I program 8 hours per day on average and my editor works exactly like I want it to, same as my fully customised desktop.
Even if it didn't save me time (which it does), I feel way more comfortable than with the alternatives.
Kate is great!
Comments like this remind me of people who complain about an error they saw on Wikipedia: "So, you're going to fix that, right?"
If you have a pain point in OSS that you care about, you can fix that. Yes, you the person reading these words right now. That's the entire point of OSS.
The build should come from the official maintainer. Period.
And participating in open source? Oh, I can assure you I am a seasoned open source contributor, but I am not going to just contribute to a random project. Wasted too much time on issues and pull requests that nobody looked at.
Easy to criticize other people, right? What have you done?
If you don't want to, or can't be bothered with the time commitment, that's fine, but realise that every time you complain about an OSS project's failings, you're really complaining about your own inability to contribute, not their's.
Wow, didn't expect someone to pull off such accusations so quickly the SECOND time.
I probably wrote more code in pull requests than your HN comments combined.
Which is that you are complaining about something you claim to be perfectly capable of yourself.
It’s not about how much you contributed elsewhere. It’s about how much you contributed to the thing you take issue with.
I get your point though, but maybe a discussion instead of an out of the blue pull request would work better.
I am not an idiot. Recent developments in the open source world should already give everybody a better idea of where they should spend their time and energy.
You've made clear that you are not going to do this. Fine. My point is that this failing you perceive then, is about your decision/inability/choice/forced situation/whatever you want to call it, to not fix it, not theirs.
If you're anywhere near as experienced as you state you are at maintaining OSS projects, you'll know the issue I'm referring to here: entitled armchair quarterbacks telling maintainers what they "should" be doing, but not doing anything to contribute themselves.
Your original remark was that kind of entitled snide, back-handed, snarky comment that deflates OSS maintainers every day.
Engage with it, or accept that's where it is. Don't race around pointing out all the things it doesn't do that you want, that you're not prepared to make happen. You could offer time, you could offer actual hard cash, you could just move on and decide not to care.
That's my point. If you have maintained OSS, you know that's the point, I even contextualised it with an easy to understand metaphor in the form of "broken things" on Wikipedia that literally take seconds to fix.
If you didn't get that on the first or second pass, perhaps you're not quite the experienced maintainer you claim to be, in which case, just hold off criticising for a beat next time, and think about what you could actually do, and if it's nothing that's fine. Move on.
Yeah, ten years ago. Now I just use the damn thing and occasionally update my plugins.
At this point, I can hardly use nano, the vim bindings are so deep in my brain.
That’s why I’ve been checking out zed/helix/kakoune lately. Zed to replace VSCode which feels bloated and the other two to replace vim. The keybindings are more intuitive to me and having auto complete of commands out of the box with a full menu showing shortcuts saved me a lot of frustration from day 0
Helix:
https://github.com/helix-editor/helix/
Like vim, but already has an LSP etc out of the box. Things are already there so the config files are minimal.
"Hey wouldn't it be handy if every webpage can download binary code and run it? Oh and let it talk to every DLL in the system as well. Super handy! What could go wrong?" - Microsoft in 1998 :)
I mean sure we were all a bit naive in the 90s and 00s but did they really not see that coming?
Uh? I‘ve always used vim out of the box, and Emacs I got it just like I like by searching the .emacs file of a youtuber who has a configuration I likes. Exactly 1 minute.
I feel this is one of those "repeat it until it is true" marketing things, like "apple believes privacy is a fundamental right"
But really, I think vscode, browsers and apple products only tangentially secure because business goals, features and convenience trump these kinds of broad statements.
I so wish it was otherwise. There are so few islands of common sense in our world and the water level keeps rising.
Now, whether the browsers or mobile OSes actually are secure because of that, is a separate thing, but those are good steps to take.
It's great that they took security into account during the design phase. I wish they had also taken into account user empowerment. They sandboxed all the apps and in so doing made interoperation, plugins, patches, mods, etc basically impossible. Now the most widely-used form of personal computer is more like a portal to digital services than it is a computing platform. It's sad to see, and I refuse to believe that it's one-or-the-other when it comes to security vs power.
I think that many software people do this. It's likely that you are more familiar with a browsers development cycle.
Docker is a technology that downloads random unsigned tarballs from the Internet and runs them as root. Also it turns off your system firewall in the process, to make all this more "convenient".
Really we have much more low-hanging fruit to pick.
They have a rootless mode: https://docs.docker.com/engine/security/rootless/
Firewall situation is mixed: https://docs.docker.com/engine/network/packet-filtering-fire...
It’s a bummer that those aren’t the defaults, but it would directly make things less convenient and therefore make people less likely to use it (same reason why installing various software is still offered as a Bash script that you curl and pipe to your terminal, e.g. Ollama; at least it’s not offered as the only way usually), what a world.
I searched, couldn't find it. what are you talking about?
https://github.com/gitpod-io/openvscode-server
For what it's worth, we have been using code-server instead in prod (prod being internal) for over a year now.
https://github.com/coder/code-server
https://coder.com/docs/code-server/FAQ#whats-the-difference-...
- https://github.com/gitpod-io/openvscode-server
- https://github.com/coder/code-server
- https://github.com/eclipse-theia/theia
I'm not sure if I'm reading it right, but the contributor graph looks like it's only 1-2 people working on each of the projects.
I think this is because the barrier to meaningfully contribute is too high simply because large code bases are almost always complicated and hard to understand.
There's a few extraordinary exceptions (NetBSD source comes to mind) but they're extreme outliers
As for the first two, last I checked openvscode-server was just enough to host VSCode for the browser, code-server had a few extras, like hosting at a subpath.
VS Code dev here. Would you like to share that list of severe bugs? Also, can you clarify what exactly isn't open-source in the entire VS Code with SSH and devcontainers flow? It's disheartening to read this, knowing that this simply isn't true.
Edit: The reason I think it is closed source is because a StackOverflow answer says so[1]. I’d be very interested in seeing the code if you could link to its repo!
[1] https://stackoverflow.com/a/55979526
[0] https://github.com/microsoft/vscode/tree/main/cli
[1] https://github.com/microsoft/vscode/tree/main/src/vs/server
> The "remote" functionality (SSH/WSL/Docker) is currently only available for VS Code proper, not 3rd party builds.
> [...] /cc @joaomoreno
Last time I checked, Arch Linux users who have the Arch Linux build of VS Code installed still cannot use remote SSH development nor dev containers. I definitely can't get it working on my own development machines.
[0]: https://github.com/microsoft/vscode-remote-release/issues/17...
Being on the receiving end of a deliberate ReDOS attack feels more than disheartening. This is not shedding a good light on the VS Code development team as a whole. This is a despicable act.
[0]: https://darmstadt.social/system/media_attachments/files/112/...
[1]: https://darmstadt.social/system/media_attachments/files/112/...
https://blog.codinghorror.com/regular-expressions-now-you-ha...
/written using pico on my Blackberry RIM. Because physical keyboards matter and pico is easy to use.
I don't. Browsers are already close to "security or utility, pick one"[0] if you try to go beyond the TV + form filling appliance experience. I don't want this kind of thinking to leak out to all software I use. Like, I'm happy to be able to write:
without worrying about rg (or anything) refusing to run because its vendor didn't set up Access-Control-Allow-Origin header correctly, or similar such bullshit that's just commonplace whenever you try to operate (instead of consuming) or integrate anything on the web. And no, I don't want to have to buy a domain and publicly spell out my computers and get them legit certificates just so they're allowed to talk with each other when physically next to each other and on the same LAN.I don't want my OS to start looking like Android either, where everything is hidden and nothing is allowed to talk to anything else - i.e. literally the opposite of the promise Android started with.
--
[0] - Security and usefulness are fundamentally opposing forces. In the limit, the most secure computer system is a dead rock.
Also seems like your idea of integration is using someone else's server without permission.
From the POV of API integrations it's basically annoyance. It doesn't prevent or discourage using an endpoint from scripts and applications except browsers, which voluntarily handle it and also don't give the end-user any control over it.
> You do realize it prevented countless script injection attacks from affecting users?
I do. We're talking about making software as secure as web browsers. I can begrudgingly accept that the World Wide Web is what it is because it is World Wide, but I don't want any of this bullshit to spill over to general-purpose personal computers. It's bad enough that we increasingly do most of our computing in the browsers.
> Also seems like your idea of integration is using someone else's server without permission.
Not server but software, and the very phrasing of it is... I don't know where to even begin addressing it.
I am not and am never gonna ask permission to use software for whatever purpose I want. That's, like, the basic philosophy of computing. Integrations - voluntary or not - are basically an extension of that. Adversarial interoperability is a sad necessity today, but we're not even talking about that - we're talking transplanting "browser security" like CORS to places and use cases where it would be mostly annoying, leaving users at the mercy of the software provider to kindly relax the security flag a bit.
How would you do Android differently?
And is there any evidence that VSCode is not secure, by Node.js standard? Has there been significant security incidents that were not handled properly? Has VSCode been neglecting security issues?
No to all those questions, based on my experience. Node.js inherently is loose on permissions -- by default you can do IO/connect to Internet however you want -- but that's not VSCode's fault. Otherwise, VSCode team has been very responsive at handling security issues.
(Saying this as an experienced VSCode user and extension developer.)
Any better product can be accused of "trying to suffocate the OSS alternatives". Do Microsoft somehow have the power to make other OSS projects suck?
The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book.
This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.
VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]:
>If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases.
Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.
[1]:https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspa...
Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.
Sadly it doesn't seem to make any progress.
I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?
By comparison, I’d say doing things over sshfs and terminals is the fiddling part.
For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.
You can use sshfs if you like. But there are many use cases where you have to do things remotely.
How often is my local machine going to have trouble running that? Having all that extra latency and bandwidth when I type sounds annoying.
There's a bit of latency between when you type and when the language server shows or hides the squigglies. But it's less than the time it takes to compile stuff anyway.
How does it execute the exact version of clangd that is running on the remote not my local laptop, desktop, or windows machine I’m using to remote in?
How well does it search through files on a slower connection when it has to download every byte of every file?
Emacs' TRAMP is pretty crap but still more reliable and user-friendly than the hot mess of VSCode remote editing.
Okay. I have been using VSCode remote session since its inception and it works well for my case.
Also, Vim/Emacs aren’t my cup of tea, so it’s not like that I have many options.
Yes, if you're using a Microsoft (c) approved and tested system configuration.
Students need to focus on fundamentals, not the fanciest automatic whiz-bang tools available. Why we learn arithmetic before allowing calculators.
> The underlying protocol on that connection can: Wander around the filesystem, Edit arbitrary files, Launch its own shell PTY processes, Persist itself
Yeah that's what SSH access gives you too.
All VSCode is doing here is installing node to run the extensions, setting up a WSS connection back the client for realtime communication. I don't see the harm there given the extensive feature set.
With vscode that exposes the local machine to the remote with support of very complex and undocumented protocol it is entirely different story.
Which is a pity especially given that VScode is browser-based and browsers are designed to allow connections to untrusted servers.
I suppose it will be a different story if VScode was designed with remote editing capabilities and treated the local stuff not different from remote. But given that the ssh extension was brought as an after thought with little regards for the local security we have the present unfortunate situation.
as always, Emacs
How is this a security problem? Is it because someone on the same network as the remote machine but without SSH access can connect the port that is forwarded over SSH?
As a user, I quite like how well VSCode's SSH system works.
VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.
Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.
I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.
I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?
Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.
VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.
For example, opening up debug ports on the running server processes, sudo privileges, or just the ability to run arbitrary code or curl in random binaries from the internet.
The article was to me a good reminder that it's a whole other level of access than just remote mounting a file system.
But then I see the clusterfucks productive people are doing and it looks like I'm onto something
That’s why we don’t take things to the limit right? That’s how you get a singularity.
The remote development workflow is intended and should be used for dedicated disposable development machines.
That's the responsibility of the operator and it is not for the tool to take care of.
https://www.jetbrains.com/help/phpstorm/remote-development-o...
Remote execution is the one I prefer. Rsync and then just runconfig. It’s lightweight and simple
> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:
- Wander around the filesystem - Edit arbitrary files - Launch its own shell PTY processes - Persist itself
When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.
For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."
https://github.com/microsoft/vscode-remote-release/issues/66...
I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/
Luckily the web version is indistinguishable from the "native" version, they did a great work there.
Just share a folder with the VM and then bind mount whatever you want to edit at the time. No need to trust the author with all your credentials.
npm scares me - if there is a way to sandbox it on a mac, I'd like to know.
Best case you go through the settings of Docker, Podman or whatever you use to limit integrations. Then, from within the VM and container see what networks, files, etc. you can reach to be sure.
I haven't tried to use it in anger, but I believe this is the likely starting point https://developer.apple.com/documentation/xcode/configuring-...
In general, I'd like to be able to sandbox more things. I'm using the app store version of slack because slack doesn't really need access to all of my files.
...assuming you have X11 forwarding disabled and/or don't have X11 server running on the same system that your client is running on.
Only technically. There are lots of situations where people (or robotic alarm bells) will be miffed if you instal your custom sw stacks, remote shells, "i don't know what these binaries are" etc on some servers you're supposedly just editing config files on.
Of course. The problem is that a 3rd party agent can now use your permission to do what it wants, and you will be none the wiser.
The train of logic has run way off the rail in this thread.
I'm using VSCodium myself anyway, but I'm also installing it from binaries (precompiled packages), as is the case with most opensource software I use.
So yeah, if you don't trust the remote machine then I agree - you probably shouldn't use it. But I don't really think that's the use-case they had in mind.
The agent is networked and running all the time so a hole on the dev server’s firewall is now a hole in your laptop’s firewall.
But it is a security problem in the same way that “curl | bash” is a security problem. An even closer equivalence might be something like “curl | bash” in your bashrc.
If you trust where you are curling from, and you trust everyone they trust and that they definitely haven't been hacked, then great! Blindly eval that code! That's what I do :)
Bear in mind that, like many bits of security advice, this is highly context-dependent. It may vary based on your risk tolerance, your level of trust in the vendor, how robust other parts of your infrastructure (e.g. threat monitoring tools, network segmentation, etc.) are.
Besides, while I appreciate the efforts of the distro package maintainers, they are overworked and can't really give the amount of care this huge pile of software in the repository needs, not to mention that sometimes their efforts are counterproductive (IIRC Debian used to deliberately break some terminfo(5) records to work around problems in some other packages). And I definitely remember reading an article (though I can't for the love of me to find it) about a Linux distro doing an automated switch from some sort of RPM-like packaging to straight-up using Flatpak, with predictably horrible results of lots and lots of broken software.
I promise, I thought about this less than you have. It's a thing we were tinkering with, and I wrote about it. That's all.
Por que no los dos? You both it. GIVE ME BOTH! Both is good. Get you a dev who can do both.
Glad to see one of my favorite blogs is still active. I was starting to get a little worried.
The first two blogs currently listed, McCord-Valim’s FLAME-Livebook-GPU and your post which has the word “murid”, truly captures the psychological arc of a developer.
Thanks!
https://www.youtube.com/watch?v=DN1Foddvez8
This is, indeed, the way.
> A compromised remote could use the VS Code Remote connection to execute code on your local machine.
I feel like that "security note" should have a CVE number next to it.
Although maybe the solution is to download a docker container on the remote (directly if it has access to dockehub or over an ssh connection if it doesn't) then run a docker container mounting the remote directory and connect to it over ssh.
The problem with only syncing files from the subdirectory is that you also want to be able to run &debug on the remote started by vscode. So plugins also need access to remote or to run remotely for some code observation that may be prohibitively expensive if run locally(pre sync of whole subdir)
Totally agree that using vscode remote on production servers is insane.
Everything else described as "bananas" sounds like expected functionality.
All you need is a well-defined .devcontainer file.
Debugging, extensions, collaborative coding, dependant services, OS libraries, as much RAM as you need (as opposed to what you have), specific NodeJS Versions — all with a single click. It's dev-environment-as-code and you can version control it.
The client and its scripts and plugins get unrestricted access to the remote system.
The code you’re editing (if not in restricted mode) gets full access to the system it’s on (which is IMO an unfortunate default but not surprising — it’s really time for development systems to wake up and sandbox the code being developed to at least be limited to its own directory tree, but that’s a different story).
The code you’re editing (if not in restricted mode) and remote plugins (no prompt at all AFAICT) get effectively full access to the client system, subject only to whatever privileges the client itself has. Yes, you read that right, if you Remote-SSH into a machine, that machine immediately owns you. Microsoft knows, and they do not care.
See, for example, https://github.com/microsoft/vscode-remote-release/issues/66...
(Some people may like VSCode to forward a port to get a local web browser to target the remote machine. Fine, make that an option. I, personally, prefer to forward the port myself.)
(Forgive me if this question sounds uninformed, I haven't used VSCode much, but if true this would not be behavior I expect from a code editor).
But it’s worse: if you download untrusted code onto a remote machine or VM and then open it via VSCode’s SSH feature, it can own your local system.
If you don't trust your own dev VM, why do you use it for development? Why do you connect? If you clone any random repository and click "trust this" - what do you expect to happen?
As far as I know, even if you don't tell it you trust the code, the mere act of SSHing to the system blows up the trust boundary, and malicious contents of ~/.vscode on the target machine can get RCE on the client machine.
And I want to connect because VSCode is a fairly nice editor and the actual Electron application works a bit better than the webpage version. But the Electron application can't bother to sandbox itself and doesn't have a security model, so there you go.
- Often gets your SSH key. Certainly gets to use your SSH agent.
- Can easily persistently compromise your web browser.
- Can trivially exfiltrate all your data.
- Has a good chance of being able to run 'sudo'.
- Can generally break Mac OS's sandboxing. (There's no shortage of examples demonstration that Apple really doesn't try very hard to make Mac OS resist attack by programs that are sort-of-sandboxed.)
- Gets all of your privilges for all of your fancy cloud services: GitHub, your favorite cloud's admin page, your email, slack, etc.
Saying "but it wasn't root" is not much comfort, nor is it even necessarily true.
Why not just run the agent locally to close the loop? I wrote an agentic coder just in the last week (open sourced it a few hours ago) that runs on the command line:
https://github.com/bhouston/mycoder
Works great and simple. Why this complex SSH setup in the first place?
VS Code has inherent security concerns due to the dynamic and unbounded nature of JavaScript combined with the attack surface introduced by its extensibility and web-based architecture. Electron (the JS interpreter used) has a dynamic web-based attack surface. Even if you mapped it out, it can change at any time thanks to the changing nature of JS standards.
Furthermore, the security issue with extensions in VS Code is well documented. And the obvious bit is it's executing code sometimes, arbitrary user code and extension code. Telementry, etc. are built in. It's really up to the user to use it in a secured manner. A lot of people just don't consider this.