This part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.
It's not. Or if it is, it's unclear. The article seems more focused on the integrity of remote development servers and deployment targets:
> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.
> 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.
The writing and perhaps messenger isn't the best :| It's describing people wanting to use VMs for sandboxed development but opening themselves up to risk from the remote machine due to the VSCode SSH Agent protocol allowing the remote server undue access to the local development machine.
It's buried so deep between "ah yes, of course you know that if you ever used the feature" that I bet the majority of readers might have missed it (me too).
MajesticHobo2 · · focus · HN ↗
Rapzid · · focus · HN ↗
MajesticHobo2 · · focus · HN ↗
Rapzid · · focus · HN ↗
It's right there in the article, not sure what to say.
MajesticHobo2 · · focus · HN ↗
> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.
> 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.
Rapzid · · focus · HN ↗
wink · · focus · HN ↗