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.
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.
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.
It seems like ssh may be the problem. I feel like there should be a way to ask for a docker like experience when ssh ing. Tell it to use is specific APIs to prevent process or filesystem access outside a particular folder (possibly allowing system binaries, although that might complicate things and require vscode to push more stuff to client). Basic googling indicates some choot options in the ssh server but nothing is mentioned on 5he ssh client man page.
Although maybe the solution is to download a docker container on the remote (directly if it has access to dockehub or over an ssh connection if it doesn't) then run a docker container mounting the remote directory and connect to it over ssh.
The problem with only syncing files from the subdirectory is that you also want to be able to run &debug on the remote started by vscode. So plugins also need access to remote or to run remotely for some code observation that may be prohibitively expensive if run locally(pre sync of whole subdir)
If you’re ssh-ing as a normal user you should only be able to modify files in that users remote home directory. You don’t need all that docker stuff just stop using admin accounts for normal access.
I 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.