> To install Zed on most Linux distributions, run the shell script below.
> curl https://zed.dev/install.sh | sh
Please stop telling people to curl pipe scripts into their shell...
> curl https://zed.dev/install.sh | sh
Please stop telling people to curl pipe scripts into their shell...
This is basically the Linux equivalent of download and double click which is a user flow that is underrated for simplicity and usability.
It will be better because you presumably use it. Chances are that the authors don't use the same distro as you do, so they are not in a good position to make a package for you.
My argument is that the install method is just piping a curl command to your shell is _no less secure_ than any other typical application install procedure, and the user experience is pretty decent.
I don't think we should be generating "loud warnings" about so called "insecure install methods" nor should we fault the Zed authors for not solving software security.
However, when source code and compilation instructions are available, an independent maintainer can verify source manually, compile it in isolation, test in it in isolation, make patches, add SELinux rules, make package, then sign the package, to produce a secure package, which can be safely consumed by end users.
Now if you use a random script from the internet, then you don't give your distro maintainers a chance to actually review the package and instead you blindly trust this script. Arguably you increase your attack surface.
Also a system package manager checks the packages (there is signatures and stuff), whereas piping a script to curl doesn't do that at all. So if the server is compromised, you just execute random code. It's harder to compromise the system package manager.
Distro maintainers in general do not audit the code they package.
Which is not the same thing as a signature on the package, is it?
> Distro maintainers in general do not audit the code they package.
First, it depends on the distro. Second, they certainly do at least some kind of due diligence before packaging a new project. So there is some amount of selection (which you don't find in npm, cargo or pypi).
In 2024, everyone looking for a code editor knows how to extract a tar.gz right?
I'll raise my hand and say I still get the `tar` terminal command options confused and have to pause and figure out the file format I'm dealing with and the options. So, no, I usually don't know, and have to look it up in the manpage/help. "Was it -xvfz for this one? Shit I just did this recently..."
That's why Flatpak exists
The Linux equivalent to double-click installer is ... a double-click installer, Flatpak. Or for even more bonus points, make the app fully portable as an AppImage. In the rare case I can't find what I'm looking for in my distribution repos, I look for an AppImage.
Maybe today. In the past, I’ve had them spit stuff all over random places— not to mention registry cruft.
Just release a flatpak, even a snap.
I’m not asking to support all distros. But at least one between flatpak and snap is enough to support pretty much all distros out there in a clean manner, not with curl | sh
good stuff snap is in pretty much any distro repo out there :D
In this case it's 150 rows with spaces and comments and the first one is
# Downloads the latest tarball from https://zed.dev/releases and unpacks it # into ~/.local/. If you'd prefer to do this manually, instructions are at # https://zed.dev/docs/linux.
Then it's a download, extract and copy stuff around, it takes 1 minute to visually parse
If an install script is obfuscated then yeah, I'd skip it too.
In all cases, signatures and repositories need to be configured, often requiring both root access and usage of the CLI and in all cases much harder than running an installer script (which might be doing exactly these steps).
To achieve easy means of installing using distro package managers means including the application in the distro itself, but now it's beholden to the distro's software update policies and thus stuck on that specific version for years or even decades.
That is not what a v0.something of an end-user centric desktop application wants for themselves.
The response of "it depends, we probably used your system package manager" was not often well received. Users who know how to use their package manager tended to just do that anyway, and not use the script.
[1] Standard “GNU”/linux desktops
In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine.
Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it?
That's super great. That has saved you from the xz backdoor and all other supply chain attacks and will be of great help to you in the future. Let's hope no backdoor ever slips past your code review.
The difference is that the attack vector of the shell script is an easier target.
If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the script could go for days undetected.
With the executable you can compare the checksum and with the whole package compiled it is less prone and more tricky to alter.
Unless that script is under monitoring 24/7, I'm going for binary but they don't support BSD anyway.
It's much, much easier to hide a malicious payload in a binary than an easily auditable shell-script. And it's much easier to make a decision of whether the payload should be enabled or not if you are already running on the local machine.
If you don't trust a publisher, you really can't run anything of theirs. Shell script or, especially, binary.
Even if it's auditable, how many people are actually verifying the shell script before hand?
You've just been given a command to download and execute.
And the potential of having lots of users downloading a shell script has a quicker attack path than users downloading the package. You have custom repos, holding their own distro packages for the software.
Also, cleaner uninstalls. If the software only has access to specific directories, I can be reasonably optimistic that removal will be clean.
Furthermore, it is much more convenient. E.g., I can just winget install vscode instead of having to google download links.
Can Linux have something like the Mac App Store where apps don't have access to the whole system by default?
Sadly code editors aren't really suitable for flatpaks, since they usually require access to dependencies installed on the host. This can be worked around by using dev containers, vor the IDE has to ne developed with sandboxing in Kind (like GNOME Builder).