Hacker News Reader

Comment by unsnap_biceps | Hacker News Reader

Just a FYI, this feature will install a binary on the remote host and run it.

> Your local machine will attempt to connect to the remote server using the ssh binary on your path. Assuming the connection is successful, Zed will download the server on the remote host and start it.

https://zed.dev/docs/remote-development

View on HN

As long as that is notified and correctly authenticated, it is a reasonable approach because the remote process can progress without having to send the whole workspace through SSH. I also expect most language servers would have to be on remote for the same reason.

It's not a reasonable approach because these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.

(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)

> these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.

Whoever makes publicly available binary blobs are necessarily aware of all those issues and try to engineer them to be resilient enough for most environments. That's why they typically work well even though they generally have little information about the system besides from most basic ones (ISA, OS/kernel and ABI to be precise). This is significantly more difficult in Linux due to its higher variability, but not even close to impossible.

They address this in the article - they're statically linking with musl, which should address most distros, and their phrasing indicates that they're testing multiple distros too.

> Unlike our normal Linux builds, the remote server can be compiled with musl, which requires no dynamic linking. This lets it work on older distros (where before we ran into compatibility problems with glibc) and on modern share-nothing distros like Nix that don't have a global set of libraries to dynamically link.

What a perfect attack vector even if Zed and Vscode people are completely honest

What’s the attack vector? Someone with ssh access to your machine can run code on your machine? That’s part of ssh.

Presumably the attack vector is that someone malicious at Zed or VSCode could change the code in the server components to introduce a backdoor that could be used later.

That's what VS Code does too, BTW.

..and is not even open source (EDIT: I'm wrong, see below). Zed's remote server on the other hand seems to be OSS. One could probably install it themselves without relying on the automatic download.

https://github.com/zed-industries/zed/tree/633b665379c18a069...

Interesting, I didn’t know the VS Code server component wasn’t open source.

it is though

? The remote server (reh) is part of the vscode repo itself https://github.com/microsoft/vscode/tree/main/src/vs/server/... there is a vscodium and codeoss builds of it too (reh builds).

The extension that invokes it isn’t, but there are a few implementations of it that are, and I think vscodium bundles one with their build. It’s just some shell scripts that download the reh build and run it with the correct args.

Hmm, are the docs outdated then or are they talking about something else?

> The Visual Studio Code Remote Development extensions and their related components use an open planning, issue, and feature request process, but are not currently open source.

https://code.visualstudio.com/docs/remote/faq#_why-arent-the...

That’s the extension which launches the server. The server itself, which is what runs on the remote machine, is part of the vscode repo itself. You can see this open source extension for an example of what the extension does as well as an explanation of what it does https://github.com/xaberus/vscode-remote-oss

Mainly just sets up the UI/connect commands in vscode UI and launched REH (the vscode server) on the remote machine. The actual server is just a different binary you build from the same repo. Non-Microsoft OSS builds of vscode work with SSH fine.

Thank you for pointing this out.

Microsoft is not the bar for what's a good solution for open source Linux operating systems.

What’s the resource footprint of that binary?

The VS Code equivalent has been unsuitable for resource-constrained servers in my experience.

Executing random binaries off the internet is such an annoying "modern" thing. I do not want that, I want to build things from (open source) source.

You can whack Zed in the head by putting in ~/.config/zed/settings.json

      "server_url": "https://disable-stupid-crap.zed.invalid",

And that stops it from doing a lot of this unwanted stuff. (Haven't tested this binary download bit yet.)

It also manages to break the `zed: extensions` page even for already-installed extensions. I sure feel like I'm being the product..

Intellij IDEA does that too, and the installer is a very big file. I suspect an entire headless IDE is installed in the remote host.

That's how most of these remoting features work, by running the IDE backend on the remote host.

I'm not sure if IntelliJ IDEA has an equivalent, but CLion has an option to just do the build and run/debug on the remote host without running the whole IDE on it.

Jetbrains provide an option to use their lightweight remote development gateway[1] and not have the IDE installed on the local machine at all.

[1] https://www.jetbrains.com/remote-development/gateway/

Gateway is just a launcher. It installs the ide both remote and local.

Reply on news.ycombinator.com