← Back to context

Comment by bobtheborg

21 hours ago

I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface

This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.

Fair enough, but running VSCode on a prod machine is also bananas.

  • Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.

    • It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too.

      It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it's setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell.

      If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.

  • agree, but do you think every dev you know konws this?

    also "i just want to edit a config file and i want a nice ui", is how you get there.

Pre-Download a known good VSCode server binary. VSCode will detect and use it.

What more could you ask for?