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.

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

This is, indeed, the way.

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

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)

Glad to see one of my favorite blogs is still active. I was starting to get a little worried.

The first two blogs currently listed, McCord-Valim’s FLAME-Livebook-GPU and your post which has the word “murid”, truly captures the psychological arc of a developer.

Thanks!

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

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

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.

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

VScode sees file changes immediately.

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.

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

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

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.

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

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.

https://xkcd.com/1053/

How is this a security problem? Is it because someone on the same network as the remote machine but without SSH access can connect the port that is forwarded over SSH?

As a user, I quite like how well VSCode's SSH system works.

VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.

Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

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

I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?

Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.

VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.

The article was to me a good reminder that it's a whole other level of access than just remote mounting a file system.

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.

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

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

The remote development workflow is intended and should be used for dedicated disposable development machines.

That's the responsibility of the operator and it is not for the tool to take care of.

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.

> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

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

When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.

For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."

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

I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/

Luckily the web version is indistinguishable from the "native" version, they did a great work there.

Just share a folder with the VM and then bind mount whatever you want to edit at the time. No need to trust the author with all your credentials.

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

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

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.

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

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.

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.

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

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.

So yeah, if you don't trust the remote machine then I agree - you probably shouldn't use it. But I don't really think that's the use-case they had in mind.

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

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

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.

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.

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.

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.

cyberduck - https://cyberduck.io/

Every day we stray further from God.

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.

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

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

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.

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?

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

Sadly it doesn't seem to make any progress.

Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.

I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?

For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.

You can use sshfs if you like. But there are many use cases where you have to do things remotely.

How often is my local machine going to have trouble running that? Having all that extra latency and bandwidth when I type sounds annoying.

By comparison, I’d say doing things over sshfs and terminals is the fiddling part.

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

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

Okay. I have been using VSCode remote session since its inception and it works well for my case.

Also, Vim/Emacs aren’t my cup of tea, so it’s not like that I have many options.

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

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.

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

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

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.

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.

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

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

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.

Totally agree that using vscode remote on production servers is insane.

Everything else described as "bananas" sounds like expected functionality.

All you need is a well-defined .devcontainer file.

Debugging, extensions, collaborative coding, dependant services, OS libraries, as much RAM as you need (as opposed to what you have), specific NodeJS Versions — all with a single click. It's dev-environment-as-code and you can version control it.

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.

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.

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

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

Yikes.

The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?

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

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

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.

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.

The only thing really keeping me using it is copilot.

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.

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.

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.

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

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?

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.

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 wonder how many other security disasters it contains that nobody has discovered yet.

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.

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.

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

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.

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.

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

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.

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

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

(Forgive me if this question sounds uninformed, I haven't used VSCode much, but if true this would not be behavior I expect from a code editor).

But it’s worse: if you download untrusted code onto a remote machine or VM and then open it via VSCode’s SSH feature, it can own your local system.

If you don't trust your own dev VM, why do you use it for development? Why do you connect? If you clone any random repository and click "trust this" - what do you expect to happen?

As far as I know, even if you don't tell it you trust the code, the mere act of SSHing to the system blows up the trust boundary, and malicious contents of ~/.vscode on the target machine can get RCE on the client machine.

And I want to connect because VSCode is a fairly nice editor and the actual Electron application works a bit better than the webpage version. But the Electron application can't bother to sandbox itself and doesn't have a security model, so there you go.

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

I agree that parts of it are open source.

Long forgotten mutagen works much cleaner, although requires a bit of a 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?

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.

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.

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

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.

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.

----

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.

nvim showed me that it's possible, with mouse events, right-click context menus, and a rich editing experience. I did genuinely try to transition to nvim but I use my mouse a lot; resizing panels, using the file tree, copy/cut/pasting files in the file browser, tabs, etc.

That's not to say nvim is bad, but after hours of configuration, I personally found myself less productive with it when compared to VSCode - however VSCode is bloated, slow, uses a lot of RAM, and SSH functionality is unreliable.

I actually started writing this as a side project - using Rust, ratatui and a plugin system based on wasm (and dynamic C libs), but you know how side projects go

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

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

As I do some googling it seems like there is now better support for that.

I'll take a look again

Note that Zed has the aforementioned concern around downloading a remote binary as well. In my case this isn't an issue, since the distrobox container is not a security boundary of any kind.

> The underlying protocol on that connection can: Wander around the filesystem, Edit arbitrary files, Launch its own shell PTY processes, Persist itself

Yeah that's what SSH access gives you too.

All VSCode is doing here is installing node to run the extensions, setting up a WSS connection back the client for realtime communication. I don't see the harm there given the extensive feature set.

With vscode that exposes the local machine to the remote with support of very complex and undocumented protocol it is entirely different story.

Which is a pity especially given that VScode is browser-based and browsers are designed to allow connections to untrusted servers.

I suppose it will be a different story if VScode was designed with remote editing capabilities and treated the local stuff not different from remote. But given that the ssh extension was brought as an after thought with little regards for the local security we have the present unfortunate situation.

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.

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

as always, Emacs

Devspace works the same way

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?

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

RAT, a remote access tool/trojan.

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.

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

What kind of SDK support are you looking for?

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

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.

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

gtfo

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

wait what

It’s the future. We live in it.

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)

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.

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

Edit: The reason I think it is closed source is because a StackOverflow answer says so[1]. I’d be very interested in seeing the code if you could link to its repo!

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

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

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

Being on the receiving end of a deliberate ReDOS attack feels more than disheartening. This is not shedding a good light on the VS Code development team as a whole. This is a despicable act.

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

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

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

What open source alternatives? Atom was a mess that kept breaking. LSP plugins are now used in almost every featureful editor and have really made editing a lot better. You spent more time configuring Vim and Emacs than they saved you. Microsoft made a really good code editor that set a standard and likely took market share from their own (mostly Windows) Visual Studio.

I do not use it anymore because of the creep of closed source plugins (+ they keep breaking my workflow) but I still think it is a great improvement.

> I wish software was secure by design, like browsers are.

Someone does not remember (or was not around) for the ActiveX or Flash days.

I trade whatever default workflow that VSCode and other IDEs are imposing for a better editing experience. And even the initial time investment is short these days due to the trove of config and tutorials online.

After learning Vim, I ditched the files explorer and embrace the buffer workflow instead. Opening many windows at the same time to peek at multiple files, then switching to a new tab only if I don’t want to lose the current windows configuration. Then fuzzy searching for navigation, and using the quickfix list for search and errors. No friction from thought to action.

Another plus for me. I have an emacs session opened for weeks now inside a VM on my desktop to work on a side project. Whatever the computer (laptops or said desktopj, it’s a quick ssh, then resuming the dtach sessiom and my workspace is ready. Multiple files opened (almost all of them), a postgresql REPL, Tasks runners, and a lot of packages (magit, project.el, consult,…) working together to streamline working on code.

You can configure VSCode with plugins. They aren't imposing any more defaults than vim or emacs do.

This is part of parent's point IMHO.

As VSCode is good enough, there is no oxygen for an open source effort to reinvent that wheel. At some point it will stale long enough that some bigger communities will want to tackle the challenge, but that won't be tomorrow.

I see VSCode as a net positive, but I think it's healthy to keep in mind the embrance->extend bigger picture.

> there is no oxygen for an open source effort to reinvent that wheel. Also, VS Code is just a great product. I mean, why is it a bad thing? It's not like Micrsoft is exerting as much negative control if at all on the whole ecosystem like Google did with Chrome. What I can see is that the dev's are keeping a good and healthy relationship to the users. While I see that this can change arbitrarily, given that it's Microsoft, right now you have (or at least I do) give them the benefit of the doubt.

The practical effect is that open builds like VSCodium don't have access to things like the C# plugin, making them not useless, but much less viable than actual VS Code.

If you want to use only open source code, you need a rebuild like VSCodium.

Thirty years, two CEOs, and at least two industry redefining tidal waves ago. The people who trot out Microsoft's HTML 2.0 strategy as a reason their work 30 years later is a trap, are deep in tin foil hat land and jumping at shadows.

Look at their wall street filings for the last decade. If Microsoft is running an elaborate EEE with their open source work, that first "embrace, extend" phase is now 10+ years in and responsible for an enormous portion of their bottom line with the fastest growth rates anywhere in the company. "Extinguish" would be suicidal.

One has to wonder if these same people also think Apple still secretly doubts the "think different" vision that Steve Jobs introduced in the same time frame, and could revert to beige boxes at any time. Or that IBM is really a hardware company and will drop services any moment.

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

Why did they buy GitHub? Well, it turns out to be massively relevant for AI. VSCode is well integrated with not just GitHub, but also Copilot, and Devcontainers, all of which strengthen their proprietary grip.

But GitHub provides free hosting? And offers freemium GitHub Actions. Open source software uses these free solutions, but in doing so make their technology mainstream, to an extent where even suggesting alternative is thought ridiculous, "just use github actions bro".

Speaking of tin foil hats, the CICD pipelines could make it possible to selectively infect binaries at the distribution level, which is virtually impossible to detect, especially if the signing keys are part of the pipeline, which I assume is almost everyone. This is critical militarily.

Cloudflare is another example of a militarily interesting freemium strategy, where a vast number of businesses have allowed a man-in-the-middle, which practically defeats TLS encryption, allowing surveillance. And, selectively and virtually impossible to prove, could hijack your cookies, and gain access to all kinds of things. And infect the binaries you download.

Which is to say that EEE strategy is extremely powerful and effective. Otherwise, why would companies surrender the security of their users so readily?

Which open standards?

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

> Apple

Is Apple thinking different ? I'm lost.

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

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

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

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.

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.

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.

Comments like this remind me of people who complain about an error they saw on Wikipedia: "So, you're going to fix that, right?"

If you have a pain point in OSS that you care about, you can fix that. Yes, you the person reading these words right now. That's the entire point of OSS.

The build should come from the official maintainer. Period.

And participating in open source? Oh, I can assure you I am a seasoned open source contributor, but I am not going to just contribute to a random project. Wasted too much time on issues and pull requests that nobody looked at.

Easy to criticize other people, right? What have you done?

If you don't want to, or can't be bothered with the time commitment, that's fine, but realise that every time you complain about an OSS project's failings, you're really complaining about your own inability to contribute, not their's.

Wow, didn't expect someone to pull off such accusations so quickly the SECOND time.

I probably wrote more code in pull requests than your HN comments combined.

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.

Which is that you are complaining about something you claim to be perfectly capable of yourself.

It’s not about how much you contributed elsewhere. It’s about how much you contributed to the thing you take issue with.

I get your point though, but maybe a discussion instead of an out of the blue pull request would work better.

I am not an idiot. Recent developments in the open source world should already give everybody a better idea of where they should spend their time and energy.

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

Yeah, ten years ago. Now I just use the damn thing and occasionally update my plugins.

At this point, I can hardly use nano, the vim bindings are so deep in my brain.

That’s why I’ve been checking out zed/helix/kakoune lately. Zed to replace VSCode which feels bloated and the other two to replace vim. The keybindings are more intuitive to me and having auto complete of commands out of the box with a full menu showing shortcuts saved me a lot of frustration from day 0

Kate is great!

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.

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.

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' {} +

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.

How would you do Android differently?

Also seems like your idea of integration is using someone else's server without permission.

From the POV of API integrations it's basically annoyance. It doesn't prevent or discourage using an endpoint from scripts and applications except browsers, which voluntarily handle it and also don't give the end-user any control over it.

> You do realize it prevented countless script injection attacks from affecting users?

I do. We're talking about making software as secure as web browsers. I can begrudgingly accept that the World Wide Web is what it is because it is World Wide, but I don't want any of this bullshit to spill over to general-purpose personal computers. It's bad enough that we increasingly do most of our computing in the browsers.

> Also seems like your idea of integration is using someone else's server without permission.

Not server but software, and the very phrasing of it is... I don't know where to even begin addressing it.

I am not and am never gonna ask permission to use software for whatever purpose I want. That's, like, the basic philosophy of computing. Integrations - voluntary or not - are basically an extension of that. Adversarial interoperability is a sad necessity today, but we're not even talking about that - we're talking transplanting "browser security" like CORS to places and use cases where it would be mostly annoying, leaving users at the mercy of the software provider to kindly relax the security flag a bit.

I feel this is one of those "repeat it until it is true" marketing things, like "apple believes privacy is a fundamental right"

But really, I think vscode, browsers and apple products only tangentially secure because business goals, features and convenience trump these kinds of broad statements.

I so wish it was otherwise. There are so few islands of common sense in our world and the water level keeps rising.

Now, whether the browsers or mobile OSes actually are secure because of that, is a separate thing, but those are good steps to take.

It's great that they took security into account during the design phase. I wish they had also taken into account user empowerment. They sandboxed all the apps and in so doing made interoperation, plugins, patches, mods, etc basically impossible. Now the most widely-used form of personal computer is more like a portal to digital services than it is a computing platform. It's sad to see, and I refuse to believe that it's one-or-the-other when it comes to security vs power.

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

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.

Docker is a technology that downloads random unsigned tarballs from the Internet and runs them as root. Also it turns off your system firewall in the process, to make all this more "convenient".

Really we have much more low-hanging fruit to pick.

They have a rootless mode: https://docs.docker.com/engine/security/rootless/

Firewall situation is mixed: https://docs.docker.com/engine/network/packet-filtering-fire...

It’s a bummer that those aren’t the defaults, but it would directly make things less convenient and therefore make people less likely to use it (same reason why installing various software is still offered as a Bash script that you curl and pipe to your terminal, e.g. Ollama; at least it’s not offered as the only way usually), what a world.

Worst IDE experience ever and this tainted the 'Eclipse' brand for me forever.

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)

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

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?

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

https://github.com/gitpod-io/openvscode-server

For what it's worth, we have been using code-server instead in prod (prod being internal) for over a year now.

https://github.com/coder/code-server

https://coder.com/docs/code-server/FAQ#whats-the-difference-...

- https://github.com/gitpod-io/openvscode-server

- https://github.com/coder/code-server

- https://github.com/eclipse-theia/theia

I'm not sure if I'm reading it right, but the contributor graph looks like it's only 1-2 people working on each of the projects.

I think this is because the barrier to meaningfully contribute is too high simply because large code bases are almost always complicated and hard to understand.

There's a few extraordinary exceptions (NetBSD source comes to mind) but they're extreme outliers

Same reason why some people are adamantly against using closed source software though at least https://github.com/VSCodium/vscodium exists.

That said, personally I use OSes like Windows or IDEs like JetBrains sometimes just because they help me get things done, it is what it is.

Also not saying that MS is somehow unique or worse than Apple, or Google or whatever, they each have their good and bad bits.

Actions like the C# dev kit license footgun/rug pull, the closed source remote development extensions, and training copilot on GPL while pretending that you own any code it generates.

You don't need even need a rant on the Windows team, it would be beating a dead horse.

:crylaugh: :crylaugh: :crylaugh: