VSCode’s SSH agent is bananas | Hacker News Reader

VSCode’s SSH agent is bananas

fly.io

737 pointszdyxry511 comments

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.

More low effort posts please!

I can't tell you how much I love that this post has generated 156 comments and I have nothing to rebut about any of them. I'm sure they're all right!

Emacs is better than vi and spaces are better than tabs!!! (I just wanted to get that in as long as you're agreeing with all the comments.)

I second both of these

Both: http://ooxx.me/wp-content/uploads/2013/10/TabsSpacesBoth.png

Tabs for indenting, spaces for aligning.

Por que no los dos? You both it. GIVE ME BOTH! Both is good. Get you a dev who can do both.

FWIW, Emacs defaults to mixed for indentations that aren't a multiple of the tabstop.

(dry gags)

Honestly, it's a great post, and I love the idea of low effort posts, so i hope you keep doing it.

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!

That, or,

https://www.youtube.com/watch?v=DN1Foddvez8

Good writing and fun, congrats! Is there a semi-hidden Monty Python reference in the middle?

Absolutely hilarious. My partner and I have this same conversation every two weeks.

« we’ve decided to just be a blog again, so: we had to learn this, and now you do too. »

This is, indeed, the way.

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.

You have definitely covered noodling

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.

There are ways to do this sort of thing with inetd, pam.d, etc.

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.

Can you give a specific example of exploitation of a theoretical bug in the agent?

They wrote "compromised" not "buggy". There does not have to be any bug. It can all work as intended... by an attacker!

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.

I sometimes kick myself for not being more productive.

But then I see the clusterfucks productive people are doing and it looks like I'm onto something

Sounds like, if you take this to the limit, the course of action is to not touch a computer?

Just like if you take eating healthy to the limit, the course of action is to not eat and starve to death?

That’s why we don’t take things to the limit right? That’s how you get a singularity.

From a security perspective, the very best option is to prevent anyone else from touching it either. Including to turn it on.

Anyone doing such remote edits on production or even staging systems is past the point of caring about any security implications.

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.

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

https://www.jetbrains.com/help/phpstorm/remote-development-o...

They have two ways — remote development, which is what you’re saying and remote execution.

Remote execution is the one I prefer. Rsync and then just runconfig. It’s lightweight and simple

he says in the article, that the agent seems to be just fucking about at will

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

This is the relevant part:

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

Is that to say that the server can do things on the client connecting to the server? That doesn't make much sense.

That's what makes this blog post worthy

"For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. [...]

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/

So this is why VSCode somewhat recently started asking if I trusted the authors/owners of remote folders.

That is why I exclusively run vscode in a virtual machine and use it through a browser tab on the host machine.

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.

Editing files on a server resulting in remote code execution apparently by design is such a classic 2004-Microsoft thing to do.

I see. I was intending to use a container to sandbox npm/yarn, it sounds like that is pointless.

npm scares me - if there is a way to sandbox it on a mac, I'd like to know.

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.

macOS has a formal sandboxing language; I first learned about it via iTerm2's build process: https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/deps.... consumed by /usr/bin/sandbox-exec https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/Makef...

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

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.

deno has been somewhat pleasing in this space, it's not a perfect boundary though

> When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client.

...assuming you have X11 forwarding disabled and/or don't have X11 server running on the same system that your client is running on.

I'm pretty sure X11 forwarding is opt-in, not opt-out? That is, if you don't run `ssh -X` or -Y then this isn't a problem

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.

Debian does this.

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.

Also read keyboard events / do keylogging

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 already have permission to do all the other things

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.

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.

VSCode is opensource. Remote ssh agent is not.

What's that got to do with anything?

that you can theoritically audit vscode code, but not ssh agent code...

Does that have anything to do with SECURITY?

The train of logic has run way off the rail in this thread.

VSCode is not if installed with binaries.

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!

How does it differ from just logging into that machine and running code?

VSCode remotes can execute code on the connecting clients, so a pwned remote server can pwn your local machine.

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.

In that it's like THAT machine is also logging into your machine, and running code there...

The agent on the dev server is now a vector back to VS Code on your laptop.

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.

There is no security issue. The author seems a bit confused.

Not surprising considering that fly.io is an unreliable mess.

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.

I have never seen a compelling explanation for why curl | bash is a security problem.

It's possible to detect "curl | bash" server side. See https://news.ycombinator.com/item?id=34145799

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?

The more I learn about how VSCode works the more it seems like it's held together with duct tape and the most cursed ideas a JS developer could come up with.

Even just from the SSH extension - the workspace URIs have two formats: essentially just the hostname and hex-encoded JSON documents. The latter case happens when additional info is needed, e.g. specific username, or... The hostname includes an uppercase letter.

Which is actually necessary because when they're saved to recent workspaces they're lowercased for whatever reason.

The SSH connections also support configuring extensions that are to be installed on the server, but don't go too crazy with it or you won't be able to connect to Windows hosts, since they're passing them ass command line arguments via CMD, which has a 8191 character limit (they're using CMD to call... PowerShell...).

It’s shit and string. Gone back to vim.

Give Eclipse a go?

Is it not written in Java?

Yes. However, today's Eclipse is only similar in appearance to its former self (I'm using it since 2002).

Has its own JRE bundled, and uses that one if you don't have any JRE installed.

Has a stable release every three months.

Starts in 5 seconds, uses ~600MB of RAM (less than VSCode!), and works very snappy.

Supports web development, C/C++, Python, remote execution and much more. Plus it has the best Git integration I have seen ever (incl. GitTower + Kaleidoscope).

In C/C++ land integrates directly with debuggers, Valgrind, etc.

The trick is, it didn't get bloated or heavier over the years, the contrary, and draws circles around everything in its class. Plus it has modern amenities like LSP support, synchronization between installations, etc.

Oh, and you can migrate it with two small XML files. Preferences and software configuration.

This does sound nice. I used Eclipse a bit 4 years ago for Java, and I switched to IntelliJ and found it to be much more usable and feature-rich, however. I don't know how much has changed since then, though.

I admit that I haven't tried Eclipse in forever (since I'm firmly a JetBrains fan) but your comment prompted me to at least kick the tires on it again

After navigating to https://www.eclipse.org/downloads/ choosing the big Download button, and but then after launching Eclipse Installer it asks me if I want Java, Enterprise Java, C++, Embedded C++, PHP, or a bunch of inside baseball stuff. I typed python in the search bar and it laughed at me. Based solely upon the description, it seems that one would have to use PHP for "web development"

Since I wasn't able to try out its Python support, I figured web development was the next best experiment. After a bunch of Next buttons, I created a .ts file, right clicked and chose Run. It opened a error dialog saying an "Internal error" had occurred. Only by diving into the details did I find "Cannot invoke java.io.File.getParentFile() because tsConfigFile is null"

But, no problem, I'll just commit this file and work on that later. Oh, wait, how do I commit the file again? There's no "Git" in the context menu. Hmm, typing git in the Help > Search offers "Show in Git Repositories", which has "Create a new local Git repository" Excellent, click that. It now offers a completely different path than the "workspace" that it asked me to pick when starting. So it's going to create a repo outside of where the files are? That's weird. But, I'm a sport. All that machinery and still no "Commit" anywhere to be found, even in Help > Search

I am not saying all of this because I think that you are Eclipse tech support, I'm saying that their DX is still stuck in 2002 so I'm glad it works for you but it absolutely does not hold a candle to modern IDEs

Eclipse is a platform, not a set of IDEs you have to install differently. What you have downloaded and installed is a “starting point”. My installation has all the functionality in a single installation.

Eclipse has two ways to install more features marketplace and “install new software”. Both are integrated to every Eclipse package you download. Python is provided by PyDev under marketplace.

Eclipse handles VCS globally and puts every VCS to their own folders. VCS features are tucked under “Team” menu. “Share Project” is what you want.

When you share a project it’s moved to its VCS folder, that’s true, but the project doesn’t disappear from your workspace view. You continue working from the same point.

Git management has its own view (called a perspective), reachable from top right. This perspective allows to manage any git repository regardless of they are your projects or not.

Eclipse has a different workflow than other tools, but I don’t find it backwards (I use BBEdit, KATE, Git Tower and countless others), every tool has a different take and that’s OK.

If you import a project from git directly, Eclipse works the way you expect.

If you still want to discover Eclipse, I can support you. If you don’t, there are no hard feelings. It’s a tool which has its own ways (like Vim, EMacs, XCode and VSCode and others). This doesn’t make it backwards, but different.

I appreciate you responding, although I actually was trying to save you the trouble by saying that I wasn't asking for tech support - it was more that I was using your comment as a contextual mini-blog/rant place to warn off others

That's because I'm cheating you: I knew about the marketplace, although Eclipse's "p2" concept drives me stark-raving when trying to setup a new instance on a machine. What I'm saying is that my life experience with Eclipse has been it is the "well, here are some components, build yourself an excellent IDE from them!" in the most user hostile way possible. It feels like the same committee that generated the Rational Unified Process got into making software. Architectural astronauts, using OSGi, to ensure than everything works on a presentation slide and nothing works when trying to run it

https://marketplace.eclipse.org/comment/8289#comment-8289 is a representative example of the same experience I've had with the "Eclipse ecosystem," showing it's not just me but a systemic problem with their release management discipline

Thank you; you just saved me 30min from testing it again, hoping it had dramatically improved. What you described is exactly how I remember it, from two decades ago.

Well, it has dramatically improved, but breaking prejudices is hard, as far as I can see.

I understand that the flow isn’t similar to what people expect, but what it provides is vastly superior to many tools I have used.

IMHO, if people can justify the time spent for learning Vi or EMacs or any other tool, it can be also justified for Eclipse.

Either way, there are no hard feelings. I’m just a messenger.

> Has its own JRE bundled, and uses that one if you don't have any JRE installed.

> Starts in 5 seconds, uses ~600MB of RAM (less than VSCode!), and works very snappy.

> The trick is, it didn't get bloated or heavier over the years, the contrary,

...and you're mentioning these features as points in Eclipse's favour ... when comparing it to vim?!?!?

I think you forgot the "/s"

No I’m comparing it to VSCode at that instance.

I also use Vim a ton every day (both remote and local). While it’s a neat editor, it’s not an IDE.

The only place I compare it to Vim is the learning curve part, and learning curve is not related to system requirements.

Almost no one using VS Code can use vim.

I use both and also IntelliJ. Why are you trying to talk down to people based on the tools they use?

I use both all the time. VSCode is fine for a lot of reasons, vi is ubiquitous on servers.

https://xkcd.com/1053/

Gold ! They can use emacs then.

I regularly use vim in the embedded terminal of vscode. (And I use vim when ssh'd in from my phone.)

Most of us have learned <esc>:q by now. And then apt-get remove vim :)

I can't use VS Code without vim bindings.

I do not personally no anybody using VS Code that hasn't also used vim. Granted there's some huge selection bias since so many people in my personal sphere use vim, but there you go.

I don't know, I found VS Code to be nicer than Eclipse. I've never had a need for SSH through an IDE, so I can't speak to that. Usually I'd just SSH through putty and use Vi if I need to do stuff on the server.

This is for remote dev, where the code you're editing exists on a remote environment vs. Local to your disk.

I like sshfs for that. It preserves the “do one thing, do it well” idea that so many IDEs seem to have forgotten.

But vscode doesn’t just let you edit files on the remote, it runs everything on the remote: extensions, terminal commands, etc. If you’re working on a web project, it forwards ports so you can still visit localhost in your browser, even though your dev server is running on the remote host.

Yeah it's like fully virtualized to run the same familiar environment completely on a local machine. It's not even remotely comparable. Extremely necessary in many cases like thin clients for machine learning

sshfs doesn't work for things where you're developing for linux and working on macos - run the code, run the debugger, step, etc.

I don't use IDEs at all and work on sshfs almost exclusively, but I totally understand where people are coming from and the difference between editing files and running code.

I use rclone for that because, while the "complete opposite of do one thing”, it (mostly) solves the extremely annoying problem of "dealing with things that look like files in potentially remote locations, each with it's own bespoke API".

(it also has, for most of my use cases, better performance that sshfs).

Sshfs doesn't pass inotify and other things, so your IDE doesn't know a file has changed (git, compiler output, and so on.)

VScode sees file changes immediately.

Eh, still, I've used stuff like Coder for remote work, or SSH and Vi.

> The more I learn about how VSCode works ...... duct tape

The most unfortunate few lines. [0]

I wish Microsoft would hire me for a couple months to do nothing but sit in a corner by myself untangling this mess.

[0] https://github.com/microsoft/vscode/blob/6dbde2a3ed308f88164...

I like it because it’s really easy to extend the editor with custom language support/tooling if you know JavaScript/Typescript. Providing custom completions, diagnostics, etcetera. I can also provide custom Go to definitions for cross-language support.

I ran the servers for our networks, binary exploitation, and intro systems programming classes, and this thing is a major annoyance. It is because of this stupid RAT that students do not understand how to use the OpenSSH client.

I've tried a few things to fix this: 1., I set a motd on our class servers asking the students not to use the VSCode remote server plugin. 2. I ran `ncdu /home` in front of the class and demonstrated how, without exception, everyone with >100MB of disk usage on the class server was a VSCode user. 3. I set a user process limit of 45, because the VSCode RAT (somehow) uses ~50 Node processes. When students inevitably ignored the motd and the in-class warning, they hit the process cap and had to ask us to kill their processes in order to get back onto the system. 4. I replaced the process limit with a script that kills all the .vscode-server RATs every 10 seconds.

Your comment is bringing back so many memories of being in university and working around the anachronistically strict limits the uni sysadmins had on the network

Ah yes, one of my favorite skills learned in school was how to work around arbitrary rules made up by cranky sysadmins! I still use it all the time.

The smart kids (whom I’m sure look like they are learning that precious openssh client) are doing their assignment locally or on a free tier VPS with VS Code and scping the thing over when it’s done.

They’re also smart enough to learn openssh when they need it IRL.

In the class which I have managed the infrastructure for, we have 1 to 2 students per VM, so this is less of an issue and there aren't any restrictions.

One of the reasons we provide the VMs is so that students can experience working in a remote server environment. The concern that I have is that these remote ssh tools allow you to bypass learning/practicing how to perform basic actions, e.g. cd, read/edit files.

Granted, as mentioned, you can scp/rsync (or git pull), but at least this seems to be more appropriate when you eventually need to interact with a real production server.

And then HN complains that new software is crap that wastes too much resources and new developers don't want to optimize resources...

In my day the new crap that wastes too much resources was the GNU software we wanted to run on the schools Solaris machines :)

I too have these fond memories, and I enjoy passing it on to the next generation :)

Doing god's work, I approve!

Can you explain why though? I get that you had to put a lot of effort into blocking VSCode but it's not clear what have VSCode caused to motivate this.

It sounds like they’re operating at larger scales, with a large number of users sharing a resource. Each user spawns 50 processes and consumes 100MB of space if they’re using VSCode. Assuming a low count of 1000 users, that’s 50K running processes and 100GB of space consumed. To enable a text editor.

100GB of storage is… not much for 1000 users. A 1TB NVMe SSD is $60. So 100GB is a total of $6 of storage… or about half a penny per user.

And that’s for SSD storage… an enterprise-grade 14TB hard drive is only $18/TB on Amazon right now, less than a third of the SSD price per TB. Call it 100GB = $2 of storage, total, to enable 1000 users to run the editor of their choice.

So, no, I’m not seeing the problem here.

If you really wanted to penny pinch (one whole penny for every 5 users), I think you could use btrfs deduplication to reduce the storage used.

That's ram, not disc.

No… it’s not. To quote the message earlier in the thread, that message said “everyone with >100MB of disk usage on the class server was a VSCode user.”

100MB * 1000 users is how the person I responded to calculated 100GB, which is storage.

He also mentioned 50 node processes, so it would be way higher than 100 MB of RAM, I agree.

Most of the RAM usage would likely just be executable files that are mmap’d from disk.. not “real” RAM usage. But, also, the 1000 users in question wouldn’t all be connected at the same time… and I honestly doubt they would all be assigned to the same server for practical reasons anyways.

It’s not easy to estimate the real RAM usage with back of the napkin math.

> I honestly doubt they would all be assigned to the same server for practical reasons anyways.

The computer science department at my university had multiple servers. All CS students got an account on the one same server by default. Access was granted to other servers on a case by case basis, based on very course-specific needs.

So yes, in my case, all CS undergrads used the same one server.

Depending on what they're doing, it could easily be multiple Gb per user. When you do VSCode remoting, pretty much everything but the UI is running on the server. This includes stuff like code analysis for autocompletion, which - especially for languages that require type inference to provide useful completions - can consume a lot of RAM, and a fair bit of CPU.

Very apparently you're counting as a singular physical person. In a big organization there's always an overhead both in time, and money, and more importantly there are more problems to solve than there are resources. So one has to arrange priorities, and just keep low-prio things in check not letting to boil over the lid.

Preventing people from using their preferred tools — tools which are extremely widely used in the real world — does not seem like a useful application of time and effort.

Usefulness depends on conditions of which we don't know a lot here. Sure, there are situations when counteracting pressure is more expensive than expanding capacity. But frankly I doubt this particular case is one of those.

This is for students, not professionals; youngster's ideas of "preferred tools" very easily take a backseat to university requirements.

How many concurrent users can you run off a single NVMe SSD?

How many students leave their coursework to the last minute?

How do you explain that the server went down during the last hour before submission deadline again, and that everyone gets an extension again, because you cheaped out on putting the cheapest possible storage into a system that has to cope with large demand at peak times?

How many students now start to do worse because of the anxiety caused by these repeated outages?

How much more needs to be invested in the university counselling services to account for this uptick in students struggling?

SSH is a fundamental protocol. If students can get through our program without learning what SSH is and how to use it, that's a problem.

Disable TCP forwarding in SSHD

who are you to decide what the students can learn or not learn?

The provider of the servers? If the students want to use their own server, I’m sure they’re free to do whatever they want. Also VS code has plug-ins that just SFTP the files up.

Students are frequently not allowed to use their own servers.

We encourage students to use their own machines. We even loan out old ThinkPads and MacBooks for students to run Linux on. Very few (3-5 per term) take us up on this offer. Most of our students would rather we do the sysadmin stuff for them.

The only requirement is that the code needs to run on our server, which they can easily check before submission.

This isn't something specific to VSCode being popular. When I was in college over a decade ago, there were students using Sublime with an SFTP plugin, coding locally and copying stuff with FileZilla or other similar GUI clients to transfer files (I distinctly remember seeing some program that was named something duck-related but for the life of me I can't remember any other specifics). Sublime in particular could be frustrating in the class I TA'd where they had some assignments to deal with processing some (very basic) machine code to simulate running the tool the class used to assemble and run the code from the (similarly basic) ISA they had been taught, which involved them using hexdump or something similar to understand how the bytes in the files worked, but Sublime "helpfully" would render the object files as as their text representation of the hexdump, with extra spacing for readability and swapped endianness compared to the way the bytes would show up if hexdumped on the school's Linux server. There would always be several students every semester who would show up at office hours unable to figure out why their code that was written to try to read an ASCII string like "AD DE EF BE " but instead would instead find some text they didn't recognize because they didn't think to look at the actual byte values, which would always just happen to start with 0xDE, 0xAD, 0xBE, and 0xEF.

> I distinctly remember seeing some program that was named something duck-related but for the life of me I can't remember any other specifics

cyberduck - https://cyberduck.io/

Aha, that does look like what I remember!

Off-topic: just one look at that homepage, the icons in particular, brought back such fond memories of the pre-flat design time. Those halcyon days when it was normal for buttons to look like buttons. (Maybe I'm just using the wrong apps these days.)

The issue is not about live editing on servers, it’s about running a process out on the server that spawns,according to GP, 50-some processes. VS Code remote editing and Sublime/any SFTP/SCP-style deploy are on completely different levels.

I was responding directly to the parent comment's decrying of VS Code as responsible for why their students don't know how to use ssh clients, not the general issue, which I agree is not specifically about live editing.

>50 Node processes

Every day we stray further from God.

SELinux exists for precisely these scenarios, use it.

[flagged]

Learning to use a real SSH client is part of the curriculum. If they graduate without this knowledge, we have failed as teachers.

Things need to be introduced at the right gradient. If you pile it on all at once, nothing is learned. If you want to teach someone how to use SSH to interact with a server, then that should be a dedicated chapter or portion of the curriculum. Once you are beyond that and it comes down to building programs, you need to eliminate that part of the gradient and focus 100% on mastering the task at hand.

Could you please stop posting in the flamewar style to HN? There was no need to cross into personal attack here.

https://news.ycombinator.com/newsguidelines.html

For those like me who were wondering what "murid" was referring to and had never heard of RAT, it stands for Remote Access Trojan.

This was a major annoyance, so you descided to become an even bigger one?

> 1., I set a motd on our class servers asking the students not to use the VSCode remote server plugin. ...When students inevitably ignored the motd...

VSCode doesn't show the motd :/

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.

The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.

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.

[1]:https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspa...

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

There's a feature request from 2018 to add a proper permission model for plugins in VSCode: https://github.com/microsoft/vscode/issues/52116

Sadly it doesn't seem to make any progress.

Just being able to deny network access would be a great step.

Lapce uses a WASI plugin system, so it could do strong sandboxing (but it doesn't).

Note that your local plugins do not get installed on remote instances without manually doing so

> I don't know what the alternative would be here

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.

Okay fair enough; just saying it seems like a reasonable alternative if you want to avoid fiddling with editors on remote machines.

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.

You really want your LSPs to run on the remote, especially with high-latency connections.

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.

I'm just talking about the language server. Obviously it's great to do the real compiling 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.

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.

VSC allows to debug the remote program, set breakpoints etc. How can you do it with just the editor?

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,…)

Yep. I, for one, couldn’t care less about picking up Emacs, Vim, or any of these modal editors. So, VSCode it is.

Emacs is not a modal editor.

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.

Running `make' works in tramp, so it can do some form of execution

It can do anything you can do over SSH

How does tramp make my autocomplete work seem I need to build on the remote machine so all the paths are in that file system?

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?

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.

> I don't know what the alternative would be here.

Emacs' TRAMP is pretty crap but still more reliable and user-friendly than the hot mess of VSCode remote editing.

> Hot mess of VSCode 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.

> and it works well for my case

Yes, if you're using a Microsoft (c) approved and tested system configuration.

I'm using it daily on a variety of Linux distros and macOS.

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.

Me, me, me, got it. Unfortunately there are other folks in the world. ;-)

Students need to focus on fundamentals, not the fanciest automatic whiz-bang tools available. Why we learn arithmetic before allowing calculators.

What did we learn? That remote code execution is a thing? That misplaced trust in [dev] tools is often regretted? That modern software design is ass? If you've been paying attention, all of that has been obvious.

SSH is a solution from the 90s. It's Telnet with a couple extra features bolted on, and despite being called the "secure" shell, is literally less secure than Telnet+TLS would be. There's so much stupid-yet-glorified bullshit implemented over SSH, because lazy assholes had a tunnel into a server with a user session, and decided "why implement a whole extra protocol for network transport and secure connections for my application? I already have an authenticated user session, in this very specific protocol, computing design, and network architecture. who care if nobody else on the planet but computer nerds have used something like this since 2000? works for me!" Discard the concepts learned from distributed OSes, ignore all the advanced AuthN+Z that had been developed, embrace the shittiest, easiest thing you can.

These "SSH agents" aren't bananas. We refused to get off our stupid lazy asses to build the right tool for the job. So we had to keep shoving more shit into pre-existing tools that were never designed for what we decided to do with it. We have no right to pretend we're surprised.

This is the world we have made. All of you, and me too. Either with your labor or your silent compliance. If it's not SSH, it's politics, commerce, school, and everything else. We live every day in the shit-pile we carved for ourselves, and every day that we don't do something about it, we throw another shovel on the pile. You don't get to sit there shoveling shit and pretend this is a fucking surprise, or crazy. You're holding a shovel.

Man, I'm getting hard tinfoil conspiracy vibes from this one. Not everything in life is done with malicious intent. Most of the time it's humans trying to do the best they can come up with under pressure.

Maybe go touch some grass once in a while, it's healthy for the soul.

Also, please make a suggestion on how to build a better SSH protocol. Complaints are kind of useless without constructive criticism.

1) I never said it was malicious, 2) humans do not try to do their best (have you looked around lately?), 3) complaints are entirely useful regardless of constructive criticism, they are literally user feedback

So, where is the RFC proposal tor something better then?

The suggestion was telnet+TLS, right? I'd not come across it before but it's apparently a thing: https://www.ibm.com/docs/en/i/7.5?topic=tls-configuration-de...

TLS is used for this inside corporate environments because it can be intercepted by snakeoil CA using firewalls.

So I'd argue it's not as secure as SSH, where an MITM actor implies a compromise of the cryptographic algorithms used underneath or an exploit like the xz case.

It's not the developers who did this, it's the "network security" people. If you block all outgoing ports except for HTTPS and ssh, everything is henceforth going to be tunneled over HTTPS or ssh.

This is also the reason why, if you allow outgoing HTTPS connections, you should as a general rule be allowing all outgoing connections except for SMTP. Because actually malicious traffic is just going to be tunneled over HTTPS anyway and all you're doing is inhibiting the deployment of any new protocols that don't take on the complexity and inefficiency of the tunnel.

And this is how we end up with clown-maxing abominations like DNS-over-HTTPS.

Every place I've ever worked that blocked ports, blocked SSH, it's no exception.

It's an extremely common exception for exactly the reason you don't like it. If you block it you get widespread breakage because so many things use it. Then even more things use it because it's allowed and novel protocols aren't.

And what do you think happens in the places that do block ssh, instead of unblocking other things? I hope you like VSCode over ssh over HTTPS VPN.

To the contrary, i find the ssh keypair authentication (and certificates) the best kind of authentication i know. And it integrates with FIDO2 without prior set up.

I wish web logins would be more like what SSH does.

"SSH agent" is a confusing term to use here, because it usually stands for a daemon that caches authentication tokens.

The "VSCode" before "SSH Agent" does the disambiguation fairly well.

I, for one, was actually confused.

Only of you already know what the VSCode agent does and then you don't need the article.

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

> 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 wonder what the use case is for this given the security implications. Staging instances that are sufficiently isolated from other environments?

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.

https://github.com/features/codespaces

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.

I've reached a level (staff engineer at MAANG) that I consider to be difficult to obtain using plain old Vim, and I've noticed that other high performers tend to still use Vim or Emacs. There's plenty of amazing developers who use VCode, JetBrains, etc. but I think there are certain personality traits - seeks out barriers to entry, likes to demagic tools through exploration, values completely open source, highly tinkerable community driven projects, etc. that explain this phenomenon more than feature set or ease of use.

When I read about how complicated VSCode's remote editing was (which I knew about before this article) it just made me want to use VSCode less. I can just ssh into a machine and use whatever editor is on the machine. VSCode's solution works, but it's also not nearly as elegant or universally applicable, and is more prone to breaking.

Also, Tramp is still quite awful, sorry Emacs users (netrw isn't any better).

The principal and distinguished engineers on my team used Vim and Emacs :P

I would imagine that is more due to age than anything else.

That is true

I agree that Tramp is not great, but there's a simpler solution that works much better: `watchexec` + `rsync`.

I can set it up to watch specific file paths, and sync exactly what I need. I'm still working on the local FS, so there's no editing delay, I can use all my local tooling, and the syncing takes milliseconds. I can also make it delete files remotely when they're deleted locally. And finally, I always have a local copy once I stop working on the remote machine, which is something I always needed to sync manually with Tramp. Plus, it's editor agnostic.

This VS Code feature would make me nervous, especially now that I know what it does.

I joined a new team that's very VSCode centric and I've been thinking a lot about why I still prefer vim. My latest observation is that I find all the toolbars and other content filling the screen to be visually noisy. I turned on Copilot and wow it's more toolbars and text is flying into where I'm trying to write. Vim just lets me looks at, think about, and write code. I can't get into "flow" with VSCode.

Oh and since people are citing age in sibling posts, I'm mid-30s. I used emacs in university and switched to vim at my first job. I used IntelliJ for a really gnarly Java project, but otherwise I keep using vim.

That's exactly what I dislike about vscode. It's so easy to trigger some pop-over that moves or obscures the precise thing you're trying to read.

The only thing really keeping me using it is copilot.

> likes to demagic tools through exploration, values completely open source, highly tinkerable community driven projects, etc.

I liked all this stuff when I coded as a hobby. Now that it’s my job, I like VSCode because I never need to tinker with it to any significant extent and I can focus on getting my work done. I fire up vim occasionally if I need to do some fancy regexp munging.

I don't tinker with Vim. I wrote my config many years ago and I touch it maybe once every few years. Otherwise it's completely rock solid.

I also find it highly amusing when people talk about needing to get work done and Vim, I mean I didn't get staff at one of the highest paying, hardest companies to climb at because I was sitting there tweaking configs instead of having impact. Vim lets me have impact by getting out of my way and letting me do precisely what I need to do wherever I need to do it.

I don’t doubt that Vim is an efficient tool for you. In the end it’s just a text editor. Editing text is not the hard part of writing code. I do not understand the impulse to judge people according to their largely inconsequential choice of editor (and I must say it seems to be disproportionately users of certain editors who are susceptible to it!)

The part of your post that I responded to talked about exploring highly tinkerable projects. I guess you’re saying that you like that Vim is explorable and tinkerable even though you don’t waste time exploring it or tinkering with it. That’s fair enough, but I hope you can at least see the sentiment that I was responding to.

Instead of working with existing remote tools it deploys a comprehensive agent that includes:

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

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.

Now I'm wondering if you could inject an emacs lisp interpreter onto the remote machine. There are exploit frameworks that do something similar.

Whether such a thing should ever be written is a completely different question, of course.

tramp doesn't require running anything on the remote server, it's more like using sshfs.

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

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

Exactly. You can use extensions without even installing them locally. They're installed on the host.

Now imagine your host is a rented VM that you throw away after use.

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.

You can have a standardised feature set, without sticking everything into the kernel.

I'm all for the former, but the latter is unnecessary.

A rootkit built right into the kernel? And apparently this is okay because it's "encrypted"? (Aka impossible to diagnose or monitor.)

Yikes.

The silver lining of all this is that your local vscode instance becomes more of a thin client, with the heavy lifting being done by the remote instance. It's perfect for the "small laptop ssh'd into beefy workstation" use-case, but less so for the "beefy workstation ssh'd into tiny VM/VPS".

If you're doing the latter, I'd recommend using sshfs or some other remote-fs-mount setup, and opening the mounted directory in vscode normally.

The way most people learned this is because somewhere in the middle of last year, VSCode's node install stopped working with the old glibc.

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 was fixed with workaround, in newer versions, they copy statically compiled nodejs to the server and it works.

Most remote access software has the same patterns as malware, no? It's only a matter of who's driving?

A related anecdote: I watched, in person, a user call into their workplace's offshore IT support, who had honestly no idea what they were doing, and kept poking around aimlessly in a remote desktop session. I remarked that, having watched tech support scam baiting videos, the interactions were honestly indistinguishable, and hopefully the user had dialed the correct number. The user was not amused.

If any of you are recommending sshfs or a like you really don't understand the benefits of full VS Code SSH Remote environment.

You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine.

You can turn any underpowered legacy machine or a thin client to a full featured workstation.

There is tons of horrible plugins that scream security threat in VS Code market place. The SSH Remote or VS Tunnel ain't one of them.

> You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine.

the same is possible with any other editor that implements a client/server model, and it can be done without giving the server the ability to execute code on the client

> You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine.

This has always been possible with ssh+tmux. And before tmux was popular, people used gnu screen.

> If any of you are recommending sshfs or a like you really don't understand the benefits of full VS Code SSH Remote environment.

Or we don't need them. Most peoples workflow is send file to remote, trigger remote. There are definitely other cases that this plugin may be more suitable for, but the trade offs for most people (which I suspect the majority of developers don't understand) are not very good.

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.

Nothing magic about the byte code, it's a compiled bit of the CI script. The whole point of Jenkins is to run arbitrary code on a machine farm.

Maybe they could make a wasm interpreter with well defined limitations. Similar to how Deno does it for Javascript.

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.

I am very confused by this post:

1. VSCode uses SSH (with its security profile) and the user can't do anything more with VSCode that they can already do with SSH. If the comparison is between a system without SSH and a system with VSCode and SSH--sure--I understand the concern, but it's an issue with enabling SSH and not VSCode.

2. VSCode can change files and persist? Well, it's a local editor, so yeah, it can change files and persist, that's literally its purpose. If that's an issue, disable editing permissions for the user.

You are not the one who's confused. The author of the article is.

The server running at the remote end can execute code on the client. If an SSH server can do that it's a security issue and a bug.

The README does warn about this: "A compromised remote could use the VS Code Remote connection to execute code on your local machine."

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

Normally on connecting to a remote machine you expect to be able to control that machine, you don't expect that machine to gain control over yours.

For local communication Microsoft Visual Studio Code often uses TCP sockets (bound to localhost) even though UNIX sockets are available. What's more, old versions used to pass the authentication token as a command-line argument, exposing it to all users on the system.

I wonder how many other security disasters it contains that nobody has discovered yet.

The proper name for this functionality is Visual Studio Code Remote - SSH (https://code.visualstudio.com/docs/remote/ssh), and it's VSCode's killer feature. With this plugin, VSCode is the first IDE to properly implement the remote IDE paradigm.

When VSCode connects to the remote using the plugin, it installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.

This architecture is not an accident - it's rooted in VSCode's origin as a browser-based IDE, and makes use of the LSP and other features that don't exist in Emacs/TRAMP because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. But the flipside is that the "client" part I described above does place a lot of trust in the "server" part, just as you might expect a browser-based application to do.

Whether you consider this architecture bananas or not depends on your security model. It's probably not the best idea to let people SSH to production using this plugin. If you are trying to rely on it to partition a novel AI tool away from part of your infrastructure, yeah, it wasn't really meant for that. The plugin predates agentic AIs by 5+ years. But it's an incredibly powerful and useful feature. I don't think taking cheap shots against it is helpful when the actual bananas thing is trying to use it in a way it was not intended for.

When is the Risc-V support coming?

> Whether you consider this architecture bananas or not depends on your security model.

Knowing about the security risks is good. In all of my use cases I control both client and server machine. The remote SSH capability just lets me use the UI comfortably on my laptop.

> VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.

Excuse me? This:

https://github.com/microsoft/vscode-remote-release/issues/66...

Is the opposite of architecturally enforced appropriate partitioning. This is “we want to make it convenient to use, and we do not care about security or enforcement of the local vs remote split at all.”

Wow. Only a genius could come up with the idea of compromising the localhost security when connecting to a remote host --- and still call the thing SSH.

Coda by panic had integrated ssh support for remote editing + terminal. Predates vscode by 7ish years.

https://en.m.wikipedia.org/wiki/Coda_(web_development_softwa...

I think that the author of this blog post doesn't understand what a development environment is! Which isn't a surprise to me considering that fly.io is such a crap service, I'm not shocked they have employees that don't understand development practices.

Remote development environments with this sort of setup are sometimes needed for applications that can't effectively run on your local workstation, or where the server environment is very different than the workstation, or where you want to ensure better consistency than a local workstation can offer.

The operating system controls the security boundaries fully. Your ops team or person who built the remote OS can limit the permissions of your remote connection's user however they'd like. It's like the author of this article forgot how Linux works: you can restrict users from running certain commands or accessing unauthorized directories with trivial ease.

And when it comes to security risks, this is supposed to be a development environment. It's not meant to be used in a produciton system accessed outside the boundaries of your organization.

It's very much the reason vscode is successfull in my opinion. They differences between local and remote development start to disappear. This is especially useful in corporate environments, but not exclusively so. At the same time vscode keeps the input latency as low as reasonably possible. It's not the best in the world, but the most integrated. And the cherry on top is the out of the box connection loss handling. Just reconnect some when later exactly where you left 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.

See, for example, https://github.com/microsoft/vscode-remote-release/issues/66...

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

Sorry, do you mean to say if I download untrusted code and open it in VSCode to inspect it, said code can pwn my system?

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

Yes, if you click yes when asked if you trust it.

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.

It's not a sandbox and not intended to be.

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.

It’s running on the remote machine, so these do not apply by default. Sudo requires a password.

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.

Maybe it's because I'm an old dog, but I was a long-time user of Eclipse before settling on IntelliJ, and I don't understand what's the fuss about VSCode.

Compared to IntelliJ, VSCode feels "messy" (I don't know how to describe it).

I'm trying to convert myself, though, because I need to work on a less powerful machine (from MacBook Pro to MacBook Air). Any tip from successful IntelliJ -> VSCode convert?

Well, I’m not going to go into the arguments about using or not; but if you are serious about the switch put something like key promoter on to learn the new shortcuts.

Most of the inertia that stops people changing is just muscle memory. Once you fix that, it’s fine.

Also, if you write plugins, check out the plugin guide. Maintaining IntelliJ plugins has driven me away; once you start writing vscode plugins you’ll find it a good reason to stay.

I switched from VSC to IntelliJ. I installed plugins to make the keyboard shortcuts and the colour scheme match.

Other than that, you'll just have to accept that any first-party support from IntelliJ will require 1–3 plugins. 3 for Java, Docker, 3 plugins for React, npm, Prettier, SonarLint, Copilot, database, Gitlens, Maven — don't be surprised if a single project becomes usable only after 20+ plugins.

> from IntelliJ will require 1–3 plugins. 3 for Java, Docker, 3 plugins for React, npm, Prettier, SonarLint, Copilot, database, Gitlens, Maven

How old is your copy of IJ that you need to download the Maven plugin? To the very best of my knowledge, every one of these in the "plugins" directory ships with IJ and is not something one needs to download from the JetBrains marketplace: https://github.com/JetBrains/intellij-community/tree/idea/25...

I obviously can't link to the GitHub repo for IJ Ultimate but the DataGrip behavior is similarly bundled. What may be up for hair-splitting is that think they do use the concept of plugins as an update mechanism. That is: I don't think one could download a copy of IJ Ultimate that doesn't speak Java, Docker, npm, database, or Maven. But they do use plugins such that one could acquire a bug-fix to (e.g.) the Docker plugin without having to re-download the whole IJ

A newish Air is relatively powerful, should be able to run an IDE. As always make sure you have at least 16GB RAM minimum.

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?

It's open source and even has long design documents, better to improve it instead of just complaining about. If your opinion is valid, some others will rewrite to fix it.

Complaining is fine, you don't need to read the blog.

I agree that parts of it are open source.

The "Remote" bits, and VS Code Server, aren't open source though.

This is my biggest issue with it. Security concerns aside, it's difficult to even debug when issues arise because of how opaque it is.

> ”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.

I should print this out, frame it and hang it on the office walls omg

It's a bit offensive, tbh. Hallucination is because LLMs can't think and don't operate on facts. To even suggest engineering is that haphazard shows a clear lack of understanding of engineering. I've had LLMs hallucinate entire libraries existing with examples of how to use them. Others have had worse. If a person did that, they're no engineer.

That's not exactly true either. Hallucinations are because LLMs aren't trained to be truthful, they're trained to be plausible, which usually coincides with the truth.

Humans have better training, but I've worked with someone who had LLM levels of bullshitting. Straight up made shit up and it worked. I'm still not quite sure why but everyone else was either too polite or oblivious to call him out (apparently that's not an unusual response to proper bullshitters).

Fortunately those people are pretty rare, but it's really a question of degree. The latest LLMs bullshit far less than they used to. Less than that guy I worked with.

Yes but would you call what that person did engineering? I certainly wouldn't.

No, of course not. But it's a tongue-in-cheek joke, obviously.

The VSCode agent is so bloated that it tends to OOM raspberrypi pies. Truly remarkable for a piece of software whose job it is to forward some text.

It's extensions that do that. VSCode with no extensions is very light.

> Truly remarkable for a piece of software whose job it is to forward some text

That is not its job. It's job is to run a whole IDE on a remote host, turning the local host into a thin client. This includes language servers, extensions etc. all being shifted to run on the remote machine – if you want to forward some text, there are significantly lighter options.

The first time I've actually checked what kind of bloat VSCode brings to a server, I stopped used it this way. No deep inspection, just in sake of Occam.

Long forgotten mutagen works much cleaner, although requires a bit of a setup.

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

https://github.com/bhouston/mycoder

Works great and simple. Why this complex SSH setup in the first place?

I wish the SSH agent weren't so stupid. It spawns so many processes just by existing that it kills a bunch of other stuff on the server. I can only use it on machines without ulimit.

Oh and it keeps old copies around after an upgrade. (Maybe this was fixed?) I've had it use up all the disk space on a small VM.

Of course, if VS Code can't be run securely on dev endpoints, that's an argument for provisioning Codespaces, right?

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.

TFA is light on details, but I have a few choice anecdotes about negative consequences of this:

----

I work on a large C++ codebase that takes quite a lot of CPU and RAM to build. To ease development access, we set-up a beefy VM in the cloud, put LXD in that, and gave every developer an LXD container of their own. Access via SSH was simple: ProxyJump via the LXD host (VM) into you container.

Now, I don't use VSCode, I use Emacs, and my container was setup by me to do everything The Right Way™. Devtools like clangd and clang-format were installed via the OS package manager. Everything Just Worked™. The VSCode users on this team had their own containers, so however their setup was didn't affect me.

Until one of them connected their VSCode to my container. My dev setup broke because their VSC decided to download a Microsoft-built binary of clangd and install it onto the PATH in my container. I was horrified, but the coworker who had (inadvertently) done this didn't see the problem. Their VSC worked just fine. I had to write-off that container of mine and create a new one.

Today, we mandate use of the LLVM-provided clangd extension in VSCode in the team, which does not automatically download anything from the internet. But this habit of "helpfully" auto-downloading LSP servers is apparently still common among VSC extensions. To the point that the Emacs lsp-mode package also offers to do that. Thankfully, it's Emacs, so it's pretty easy to disable that behaviour.

----

As we SSH into machines quite a lot, we strongly discourage per-container SSH keys and strongly encourage SSH Agent Forwarding instead (with per-use confirmation). VS Code found a way to break that too. But we couldn't wait for the VSCode overlords to fix it — we were affected already, and urgently needed a fix — so we looked into what could be happening.

Turns out, VSC hijacks the way your shell loads, all so it can inject arbitrary stuff into the embedded terminal. You think you know how and when bash loads ~/.bash_profile and ~/.bashrc and so on. None of that matters because VSC uses its own homebrew init script for bash. A script that tries to, emulate how bash loads, though not entirely accurately.

If you're building a terminal emulator and you want shell integration, the correct way to do it is to ask your users to load your terminal's support code into their shells. The VSCode way is to never tell the user anything and just silently take over their shell for them.

----

Now, I no longer even try to support VSCode on the team. VSCode users are on their own. I help them setup Vim, NeoVim, Emacs, or even IntelliJ. If they have to have VSC, I might look into Eclipse Theia. But, as far as VSC is concerned, I expect nothing less than this malware-style behaviour and thus refuse to waste my time on it.

And I'm guessing none of that was documented. This is the other half of the problem - I can't even know what it's doing without a bunch of reverse engineering

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.

Thanks for the recommendation. Just looked it up, I'll give it a try!

EDIT: https://helix-editor.com/

I love that the homepage has a video showing usage. Such a great way to demonstrate it.

Have you tried Zed?

Yes I have. Last time I tried it, it didn't have SSH support (I'm on a MBP so my life involves around remote development tooling).

I'll take a look again

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.

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

Yeah that's what SSH access gives you too.

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.

I don't think this is true and I don't think it's what the post says.

https://github.com/microsoft/vscode-remote-release/issues/66...

VSCode remote editing trojan is the only remote editing mechanism that actually works.

Tramp might be good in imagination, but in reality it's just a poor plugin that sometimes works, and even if it works, it's only good for some use cases.

the answer is in the blog

as always, Emacs

Security has two aspects:

Objective security - things like do not open mongodb server with default passwords to internet etc. which are definitely bad.

Subjective security - blogs and consultants saying something is bad and do not have objectivity to back it. It may not be a bad things, ugly sure, but it would need lot of context.

It could be bananas, ugly etc. but may not bit a big deal. Sure things, go wrong white remote editing. Did I bring a server down, you could do the same while VI thinking it UAT but it turns out to prod or rm a mount.

Are millions of orgs doing this day-in day-out? yep.

I found this out the hard way as some servers had a high cpu load and a weird agent that i did not install. After having a heart attack and assuming an intruder i discovered vscode had injected some agent that was stuck walking the servers filesystem and consumed 100% cpu on one core. On the one hand i love how having a server open in vscode feels especially as things like the docker extension work pretty well but on the other hand i really wonder if it requires these nightmarish sacrifices.

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.

> because everybody is using VSCode now

Are they though? I don't have numbers right now to back this up but last I remember, people were leaving VS Code, not moving to it.

I'm sure there's some bias here but the best numbers currently available show it's still staggering https://survey.stackoverflow.co/2024/technology/#1-integrate...

You're going to have to provide a source of you want to claim otherwise.

As someone that always favoured X Windows, and mastered enough vi when (X)Emacs wasn't available on the development server/production system, never bothered with tramp.

Likewise with VSCode, now 30 years later, one of the few plus of it being Electron based, and having started its life as browser based app, is that the browser has replaced my X Windows session.

So don't really care how much bananas the SSH agent happens to be.

This is a perfect use case for unveil(): you have a program that wants to operate on a specific directory (your repo), and never outside of it.

Dev tools are written with people running macOS. They already have trouble following XDG instead of polluting one's home directory, imagine asking them to use unveil.

Also AFAIK unveil is an OpenBSD thing. Does VSCode even do BSDs? chroot is POSIX and none of the junior devs employed by Microsoft are aware of it.

Of course, I meant this is an argument for other operating systems to implement a similar syscall. Maybe NT/Darwin have something similar that I'm not aware of.

A simple solution is to use bubblewrap locally. Only bind mount specific directories into it and a copy of your vscode config (which you could merge any changes back if you need). Then you can install random extensions and let the AI wreak havoc generally without it leaking to your main system. On arch linux bwrap'ing vscode also seems to work without zypak.

I’ve been using Zed for some time and like it a lot. Much faster and lighter than VSCode and works great for Rust and C/C++. Haven’t tried it with JS or other languages yet. Took a little customization to get it how I want it, but not hard.

I might buy Zed’s cloud stuff just to support them even though I don’t need it.

> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion

I would argue that "lives off the land" is a poor analogy, and is much more like what VSCode does.

Tramp specifically does not live off the land. It has a supply line back to home base; all its resources come from home.

Tramp goes into the woods with nothing. Finds a rock and throws it at a rabbit. Finds some sticks and rubs them together to make a fire and cook the rabbit.

VSCode doesn't look around for rabbits, sticks, or rocks. It brings an RV with a fully stocked pantry and kitchen.

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.

I don't remember, but if it can do ESC-. (which IntelliJ's can't and which I try to use multiple times per week, I'm not learning) it's less bananas than that one, for me.

I'll take VSCode "insecure" ssh agent over Emacs Tramp any day of the week because it actually works.

Sometimes you just gotta be pragmatic and use the stuff that works and makes your life easy.

"The underlying protocol on that connection can:

Wander around the filesystem Edit arbitrary files Launch its own shell PTY processes Persist itself"

Given that this was the solution, what was the goal?

https://github.com/devspace-sh/devspace

Devspace works the same way

I'm DevOps and don't pretend to understand good code layout in large projects, but why would you keep a "printTime" function in remote extension management code?

https://github.com/microsoft/vscode/blob/c9e7e1b72f80b12ffc0...

(Genuine question, I'm puzzled!)

You don’t know/care and the reviewer doesn’t care. The code was probably written by an llm helping enforce the not-caring.

Are you OK? I just asked a question, which implies that I cared enough to at least ask.

No I think it implies that you wanted to appear to care in order to make a point.

oh. I really didn't, can you tell me what made it sound that way? I'm autistic and freely admit that I get words incorrect, and miss contexts.

I'm mostly OK at programming, but I like to learn, and HN is full of people who are much, much smarter than me who also like to share their knowledge.

Thank you for replying. I wasn't trying to make a point, I was just trying to learn why a seemingly utility function wasn't in some shared /lib/timestamps.ts or whatever.

I won't bother you further.

I didn’t say I was bothered, and I don’t think you were attacking me. I don’t think you misused anything and I fully grokked your context.

Sorry if my reply came off as snark or disgruntled.

Yes I am okay, my original comments was to make a point about general populace’s level of dedication to their employment and interest in the strict rules of good software design. The original commentary was a bit snarky.

Thank you for asking if I was alright it, it is important to reach out when snarkiness cannot be discerned from distress.

Did you try searching in the file to see where the function is called? It’s used in some log messages.

I'm not really asking about its function, more its location. I figured stuff like that belonged in /lib/ utility code so it could be reused consistently across the codebase.

Basically I'm not a great programmer so when I see stuff that I am unsure of, I ask so I can learn.

This functionality has worked great for me as a web developer working on huge websites. I have not experienced any issues

> because everybody is using VSCode now

Maybe I'm living under the rock, but I know only 2-3 people that are using VSCode

It's extremely popular: https://survey.stackoverflow.co/2024/technology#1-integrated...

But anecdotally, nobody in my office uses it.

Thank you for this - it dissolved an assumption I had about vscode ssh - that it was similar to Tramp

what is the type of application that was hinted as being murid? I couldn't crack that one.

I think it's RAT (remote access tool)

VSCode is a perfect fit for most of the projects it is used for on an internet gone bananas.

My days of not trusting a single thing microsoft controls are certainly coming to a middle

"[LLM-generated code] is ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup). There’s lots to say about this, but for the moment: it’s a semi-effective antidote to hallucination: the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates."

Okay, so who's doing this today and how?

This question came up recently in the Aider discord and not many had a good answer.

Aider is great but the SDK is weak and second-class, so interacting with the repl frustrates agent-dev.

Sidecar (which can run independently of Aide IDE, not to be confused with Aider), https://github.com/codestoryai/sidecar/ is one agent that was mentioned. Many of that projects issues are auto-responded to by a PR-creating agent.

Anything else I'm missing?

In general, I know how I would build an agentic dev-loop, I'm just looking for a good SDK that handles prompting and diff merging etc. i.e. Aider as an SDK or similar.

Hey I am the coredev on sidecar. The reason you see autogenerated PRs is cause I am using our agents to write the code for the agent lol

The big difference is the complete loop, each PR gets its own VM with the tool chains installed so the agent can run cargo check or cargo tests etc.

We do find the LLMs of today are not the best elite engineers but very very competent junior engineers. It's been a weird but eye opening workflow to use.

I am super interested in sidecar. When will it support o3-mini-high?

I also need an SDK to script it, tbh. What I want is to have actually a few different agents that interact with each other. Do you expose a good SDK?

I does support o3-mini-high already, we use it for a few flows in the agent.

What kind of SDK support are you looking for?

pretty on par with the dowload the world as dependecies trend.

Works great for me, idk what you all are doing wrong

I am still using Sublime Text, for some reason.

Because Sublime Text is awesome and has yet to be surpassed by other editors, that's why.

rolled my eyes at the sidenote “”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.”

gtfo

that was the best line!

murid, noun, Any member of the Muroidea superfamily of rodents.

RAT, a remote access tool/trojan.

Can you say, "RCE"?

> they’ll iterate on your system configuration just as happily on the Git project you happen to be working in

Ehhh... no they won’t? Unless you give them access, of course.

>> VSCode mounts a full-scale invasion

I love to read articles that have a bit of humour(no offence to VScode people); somehow, it seems one can connect more with the writer.

Thank you, kind stranger on the internet. You made me smile when I most needed it :)

> the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates

wait what

Cursor does exactly this and it’s pretty wild the first few times it happens. Then you realize it does it only sometimes so you change its “English script prompt” file and make it do a full lint scan so it catches all the linter errors and then you watch it fix something in a wrong way so you stop it and ask WTF it was thinking, and then it apologizes and 50% of the time does the fix the right way and 50% of the time you chase a rabbit hole. Also sometimes it selectively ignores some of your script file prompt so you have to reprint and tell it to fix its script in a way that ensures it understands it… and it does that so you commit the new script document to git (or have it do it)

It’s the future. We live in it.

is murid short for remote access greek horse ?

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.

Theia embraced the Monaco editor. Are extending it and now are trying to extinguish VS Code.

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

(they are just memes, with a pinch of truth)

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.

Vscodium is open source, and ssh mode works. I don’t think copilot does.

Cline, Roo, and Continue all work with Codium though, so it's not a big loss.

Since when? Last time I looked the remote ssh plugin wasn't open source and refused to run on forks?

There is an open source reimplementation (or two?)

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.

this looks like the chromium version of vscode, so long as we're both talking about the same thing: https://vscodium.com/

Zed. It is written in a compiled language and it’s C++ extension doesn’t take down my servers.

Ohh, interesting to see they have Linux builds available now.

Zed was in the news recently for the exact same security flaw.

VSCode is great. If it suffocates other products, that's their fault for not being better. MS hate for hate sake is fucking old, do better.

I don’t think people like the principle behind it: https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

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.

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.

But several plugins on the VSCode side ar closed source.

You can write non-open source emacs plugins, too.

Emacs doesn't ship with them or nag you to install them.

emacs specifically is not legal to distribute those plugins because of the GPL. Yes, you can be sued over this, likely won't, but you can be.

The GPL's use of linking is rather nebulous.

> What open source alternatives?

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.

> embrace->extend

You people need to get a new catch phrase, hard to draw a connection between something MS created and "embrace, extend, extinguish"

The "catch phrase" came from MS, not the broader community. It was official policy for some time.

Yes, 20 years ago. Let go.

It is more relevant than ever with all the blantant openwashing occurring everywhere.

> It was official policy for some time.

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.

The Fuhrer is making a big barnstorming comeback these days. Perhaps it was a prescient part of IBM's long term strategy.

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?

> It embraced open standards. Then extended them with proprietary plugins. And then extinguished alternatives by making their plugins incompatible.

Which open standards?

What software existed before VSCode that would somehow have been compatible with VSCode plugins if not for this imagined villainy?

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

> Apple

Is Apple thinking different ? I'm lost.

Which company is still top of the list on forced upgrades/telemetry/breaches and numerous other anti-consumer moves, this year?

https://news.ycombinator.com/item?id=31718168

Unfortunately, we're not anywhere near "letting it go."

Vscode is open source

The components the post is talking about are not.

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?

It is against their TOS :)

>> What open source alternatives?

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

> You spent more time configuring Vim and Emacs than they saved you.

Doom emacs + Evil is basically free in terms of config time and it’s wonderful.

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 haven't tried this one but I tried SpaceVim which threw error messages and was slower to start than VSCode --> I switched fully to VSCode.

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.

> You spent more time configuring Vim and Emacs than they saved you

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.

>What open source alternatives?

Kate is great!

It's not, it's very buggy.

Also its Vim implementation is horrific

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.

I've been using it for 15+ years and somehow never noticed that.

You did and you're lying.

Zed is now open source. It’s new, and it’s great!

Sure but it does not work yet on Windows...

That's a feature.

You can build it for windows, that's still massive for an early project

It does, you just have to build urself

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.

my "own inability to contribute"

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.

You haven’t really refuted his point though?

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.

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.

>You spent more time configuring Vim and Emacs than they saved you.

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.

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

> What open source alternatives?

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.

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

> I think it's more a case that > browsers take security into > account at the feature design > phase.

I think that many software people do this. It's likely that you are more familiar with a browsers development cycle.

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.

They’re working on signing: https://docs.docker.com/engine/security/trust/

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.

This is pretty much exactly why I've never used Docker up to now, as cool as it seems.

"Runpod's openvscode-server"

I searched, couldn't find it. what are you talking about?

I'd guess that there was a mixup:

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

How would you compare the three options,

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

[1] https://stackoverflow.com/a/55979526

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.

[0] https://github.com/microsoft/vscode/tree/main/cli

[1] https://github.com/microsoft/vscode/tree/main/src/vs/server

You should have asked Bing to filter your thoughts for you before you posted.

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.

[0]: https://github.com/microsoft/vscode-remote-release/issues/17...

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.

[0]: https://darmstadt.social/system/media_attachments/files/112/...

[1]: https://darmstadt.social/system/media_attachments/files/112/...

I get what a regular expression like that does, but what leads to it being executed?

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.

Now you have two problems!

https://blog.codinghorror.com/regular-expressions-now-you-ha...

Just here to say that the editor wars this comment kicked off are classic. It’s comforting to know that some things never change.

/written using pico on my Blackberry RIM. Because physical keyboards matter and pico is easy to use.

How does VScode promote C#? I have tried writing C# in it and it was a mess. Visual Studio is much superior.

VSCode promotes Visual Studio by being terrible at C# development. /s

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

How would you do Android differently?

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?

Yes vscode is awful. Zed ssh does a far better job. But we are living in an awful world.

Zed also downloads a remote agent.

And toolchains without asking:

https://github.com/zed-industries/zed/issues/12589

What are you yapping about? Zed does it in the same way.

It's much lighter

It’s “lighter” on features too.

> because everybody is using VSCode now, and, in particular, they’re using forks of VSCode that generate code with LLMs

:crylaugh: :crylaugh: :crylaugh:

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

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?

You read the article right?

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.

Reply on news.ycombinator.com