On: VSCode’s SSH agent is bananas

[jazzyjackson]

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?

[throwanem → jazzyjackson]

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.

[regularfry → throwanem]

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.

[kreyenborgi → regularfry]

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

[regularfry → kreyenborgi]

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.