I find that VS Code's Remote-* extensions work well. I'm currently writing a Terraform provider on a remote Linux box using Remote-SSH and everything feels local. Compilation, etc happens on the remote and if I were serving requests it's dead easy to forward a port.
I like the remote editing stuff in VSCode, but I often end up having to rsync things at some point since I need to test code on remote servers, but I sometimes need access to other resources only available on my local machine. I can use VSCode for the editing, but I can use mutagen for the syncing. VSCode also ate some of my remote work before so I started using an extension that created periodic backups on the remote so that if it happened again I wouldn't lose much if any work. That hasn't happened in a while, but it was bad enough that I want to ensure it doesn't happen again. I tried an rsync extension, but it was flaky and poorly maintained. With something like git I'd have to create WIP commits, remember to push & pull and then remember to clean up the changes before merging.
That sounds interesting but I can't find any mention to it in the docs. In fact, it sounds like it's just copying files over to the remote and running commands there.
Are you able to provide a reference to how Mutagen secures my code on an untrusted remote?
The general philosophy with Mutagen is to (a) delegate encryption to other tools and (b) use secure defaults (especially for permissions).
So, for example, Mutagen doesn't implement any encryption, instead relying on transports like OpenSSH to provide the underlying transport encryption. In the Docker case, Mutagen does rely on the user securing the Docker transport if using TCP, but works to make this clear in the docs, and Mutagen is generally using the Docker Unix Domain Socket transport anyway. When communicating with itself, Mutagen also only uses secure Unix Domain Sockets and Windows Named Pipes.
When it comes to permissions, Mutagen doesn't do a blanket transfer of file ownership and permissions. Ownership defaults to the user under which the mutagen-agent binary is operating and permissions default to 0700/0600. The only permission bits that Mutagen transfers are executability bits, and only to entities with a corresponding read bit set. The idea is that synchronizing files to a remote, multi-user system shouldn't automatically expose your files to everyone on that system. These settings can be tweaked, of course, and in certain cases (specifically the Docker Desktop extension), broader permissions are used by default to emulate the behavior of the existing virtual filesystems that Mutagen is replacing.
For files at rest on the remote, I guess I assumed files would be encryted on the remote with a local key since GP said "one can develop on untrusted remote machine" and "VSCode remote always assumes that the remote part is trusted".
On an actually untrusted remote, removing group read permissions doesn't do much to secure my code.
The only scenario where it's helpful is a system with multiple non-admin users, perhaps like a university lab computer but who's doing sensitive work on those anyway?
In many ways Mutagen and VSCode's remote extensions are the same idea, with trade-offs in terms of flexibility vs. integration.
Shared systems with multiple non-admin users was one of the original motivating use cases for tighter default permissions.
I don't think there's any scenario where one can perform truly secure development work on an untrusted system. You could certainly store encrypted code in an untrusted location, but there's not much you could do with it on that system (without a hypothetical compiler or tool that maybe supported some sort of homomorphic-encryption compilation operations?). Even decryption on-the-fly for processing by regular tools wouldn't be secure on an untrusted system. And running any code there would be equally insecure.
I'd imagine that for any seriously sensitive work, one would only want to work in highly controlled, trusted, and firewalled environments. If there's a scenario I'm missing though, definitely let me know.
Just to be clear, when I mention sensitive work, I'm not necessarily talking about national security, military, etc. kind of work. Any work for a client is sensitive enough that I wouldn't do it on any remote I (or my client assuming there is approval) don't control.
I will try Mutagen at some point. The fact that it's editor agnostic is certainly a big sell!
