The Audacity of Piping Curl to Bash

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind.

I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

>An installer [... is] there to copy files to your system and then modify your system so that it is ready to use the new program to the deepest level that makes sense

Sure, but what's the corresponding step in the zsh "install"? Looks like copying over their ~/.zshrc. The "install" script could have chosen to clone the git repo, copy the file, then print "all done! run 'zsh' to start your new shell!' or whatever

The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update)

> devs don't like packaging for every distro under the sun

source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unless you have some funky dependencies (and if you do, installer will also be complex)

RHEL/Centos RPM will cover near-whole rest of the market.

MacOS/FreeBSD will be different enough anyway that you will need to write a bunch more in install script

Building simple package that just delivers binary is not even that complicated. Getting them to pass distro muster is often harder but you don't need to do that.

> Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal.

Most of those "arcane" policies are there so random incompetent dev won't fuck up other stuff in the system. Which is also why users want packages in the first place.

And you don't need to abide to any policy to make simple package that just puts your files on the system. Building dumb debian package is just few metadata files (post/preinst scripts + a file describing your package) in a directory and a single command.

You only need to worry about policies if you want to submit package to distro, and there are in place for a reason.

No shit they are better for users, that's their entire fucking point!

With things like the OpenSUSE build system... I see this more as a one time cost

You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever

With that you parameterize the inputs. The version to build, where to get the sources, etc.

Maintaining these is... note your build/runtime requirements the same way you do while developing.

Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien

I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own.

I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro

I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some kind of medical/legal-like software-engineering bar association) that devs either properly package their apps, or don't release them at all.

I'm not saying it's a good idea; just saying that it's probably the solution brewing in the back of the minds of people who write things like this.

Even if omz had a package-managed package, it would do the basic curl|bash itself the moment it was installed, to update itself. Technically it's git and things, but that's all the curl|bash does anyway.

> I think what's missing is some standardization around what an installer is allowed to do

I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system.

I tend to agree with the author here, but I'm sympathetic to the maintainer: packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream. With that said, it is a mature, standardized process, and is fairly painless in the self-hosted/non-upstreamed case.

>I think what's missing is some standardization around what an installer is allowed to do and flags to tell it when to make certain changes as well as explicit logging for what exactly was changed or added where, but that's not going to be solved if everybody has their own bespoke bash script for installation.

YOU ARE RIGHT!

What's more, we can make common installer code so everyone could just use same rules and documentation to customize it to their liking.

And once we have many apps using it might even be integrated into system so you don't have to download as much, and all the bugfixes are in one place so we don't have thousand different install scripts

Once we have that we can just make a very simple data file format, say just a data.tar.gz for data and control.tar.gz for telling installer what to do. As for metadata, just write simple file, say

    Package: my-tools
    Version: 0.0.1
    Section: base
    Priority: optional
    Architecture: all
    Maintainer: Someuser <some@email>

And if that's one format, we can it manage uninstalls too! Just put a simple text database of those files.

OH WAIT THAT'S A FUCKING DEBIAN PACKAGE MANAGER

This is kind of my take on it. As gross as I find pipe-to-shell installers to be instinctually, I can't really think of any objections I have about them which don't apply to just grabbing a package from MacPorts, save for one: MacPorts gives me a unified interface for listing and uninstalling that software after it's installed that I don't get from ad hoc installers. But in terms of the common complaints like security, it's pretty much the same - it's not like I'm auditing the source or patches of all the software I'm installing via MacPorts either.

If curl dies early, bash might be executing a truncated script. Arbitrarily truncated bash scripts are often valid bash scripts that do things you don't want.

Cargo does not. Rustup’s installer does, by default. It informs you of this before it does so, and you can ask it to not if you’d prefer.

I used to think that.

But is it really that much worse than `pip install` random stuff? Or Homebrew, or Linux package managers - it's not like these things get audited.

That is kind of nonsense. If someone already has hacked or MITM'd the server offering the install script payload the game is already up. No attacker is going to bother doing that, since the number of people who read the install script before sending it off to bash is minimal.

And every time you post it, a bunch of people point out that there is nothing going on here which package managers or installation executables can't also do.

They are. XDG is one of those grand ideas that a few developers really wished everyone else did... but it isn't actually that important so most of the world doesn't bother or never even hears about it.

> Entire programming languages like Rust depend on this to install the compiler

And it works! For people who have to stay on top of language changes (not everyone), who are on a wonky platform or that doesn't update quickly enough, this is actually a pretty okay method. And they do also offer alternative methods: https://rust-lang.github.io/rustup/installation/other.html

Here, the "You know what they should be doing..." attitude surely doesn't account for something.

> rustc changes too fast for anything but the most rolling of distros to keep up

This may have once been true, but isn't really anymore. Ubuntu updates all distros with the latest and greatest and does so about every couple of minor version releases (last was 1.59 to 1.61). This is fine for me. My MSRV is now whatever Ubuntu is shipping.

It's one way out of several to install rust. And interestingly enough, my distro maintains a more up to date rust than I do myself.

XDG is a specification of Free Desktop, a body that I don't trust. Standardizing filesystem locations can't be a bad thing; but an awful lot of it is tied into the requirements of GNOME Desktop, a project which seems to be trying to rule the world, and which I don't want to help with.

Perhaps if XDG were cut loose from the Free Desktop project, more developers and maintainers would pay more attention to it.

Not always. Lots of programs that do this might be targeted for intermediate users. Brew is the first thing that comes to mind.

I seem to recall a case of a certain application that uses curl to bash to install docker, docker-compose and finally create its containers. The problem lies with the fact that said script committed the mistakes of trying to pull docker from Docker repositories instead of using the one from the distro and also thinking $distro_based_on_ubuntu (I think it was Mint) is Ubuntu. A mess was made and I had to help some guy to fix it.

I don't remember all of the times I've encountered it but a couple of examples I remember are rustup with its 700 lines of shell script (although you can install rust normally of course) and pi hole with its whopping 2700 lines of shell script.

Some package managers don’t really prevent this, particularly thinking of npm but also apt and other system package managers, because they can run arbitrary post-install scripts.

As always, you need to trust the vendor of software you install and/or do an audit of the source/installer regardless.

> You do not take liberties with someone else's system, there is no need to do it and no excuse for it.

The whole point of the oh-my-zsh installation script is to modify your system to work with oh-my-zsh. If you don't want your system modified, you shouldn't run it: there is no other point of that script.

Build instructions are a completely separate thing, and are a complete distraction. No one sane waits for some random distro to discover your software and decide to package it themselves as a means of distributing it.

As far as most people are concerned, the role of things like apt or rpm is to manage the base system. Installing and keeping application software up to date is best left to the applications themselves - as it has always been on Windows or MacOS (before the app store craze), as it should be. It is not and should not be up to the Debian maintainers to tell me what version of Firefox to use, or how often I should update it.

Edit:

> Respecting the possibility that a config file or even the bins and libs might already exist as part of the "make install", are just part of the job like writing the software itself, not some unreasonable extra burden.

I assume you are referring to the author's complaint about the installer overriding their ~/.zshrc. If so, then that is again a misunderstanding of the point of this script - it explicitly tells you right in the description that it will do that AND it keeps the old file around in case you still need it.

To explain again - oh-my-zsh is a system for controlling your zsh installation. It's whole purpose is to take over things like your .zhsrc file. This is explained very clearly on their main page, so running that script and expecting it to not modify your zsh settings is like installing Firefox and expecting it not to connect to the Internet when you type a URL in the address bar.

Homebrew is Homebrew for Linux. You can install and use brew(1) on Linux. The Homebrew github worker even generates linux/amd64 binary "bottles" for each Homebrew package to make it fast (as long as the package doesn't explicitly opt out of Linux support.)

> "homebrew for linux" type package manager that could safely manage software without conflicting with OS packages.

As someone who uses Homebrew for Linux, I can say that "without conflicting with OS packages" cuts both ways: fine, I get more modern stuff than apt could imagine, but having to monkey with the LD_LIBRARY_PATH or -Wl,-rpath over and over gets old real fast. I have no idea why they tried to be so cute putting things in a stupid directory (/home/linuxbrew/.linuxbrew) instead of /usr/local like they did with Homebrew for Mac (err, not the arm64 version, where they went back to /opt/homebrew for whoknowswhy)

> GPT-3, please explain the above in simple English a five year old can understand.

Doing something called "piping curl to bash" is not a good idea. It's like trying to do something on someone else's computer without asking permission first. It puts you in the place of being in charge, even though it isn't your computer. Doing this can cause trouble and make the person who owns the computer very unhappy with you.

> OK, now explain the above in verses of King James English.

    Behold, the ground thy code doth touch, 
    Is holy and hallowed much.  
    The rites of Posix and decree, 
    Beseech thee not to speak unless spoken free.  
    Alone thou approachest the throne divine, 
    Unless in favor of God's law thine.  
    To wield the sudo sword alone is sin most dire, 
    And damnable contempt before heaven's fire.  
    Forsooth 'tis treason unspeakable this day! 
    curl|/bin/bash shalt thou never say!

I've never been much for religion but maybe I just haven't gotten into the right stuff. Can I confess to you the sins of my .vimrc?