Long ago, in days of yore, we assumed that any software worth having would be packaged by the operating system we used. Debian with its enormous pile of software (over 20,000 sources last time I looked) looked to basically contain every piece of free software ever. However as more and more people have come to Linux-based and BSD-based systems, and the proliferation of *NIX-based systems has become even more diverse, it has become harder and harder to ensure that everyone has access to all of the software they might choose to use.

Couple that with the rapid development of new projects, who clearly want to get users involved well before the next release cycle of a Linux-based distribution such as Debian, and you end up with this recommendation to bypass the operating system's packaging system and simply curl | sudo bash -.

We, the OS-development literati, have come out in droves to say "eww, nasty, don't do that please" and yet we have brought this upon ourselves. Our tendency to invent, and reinvent, at the very basic levels of distributions has resulted in so many operating systems and so many ways to package software (if not in underlying package format then in policy and process) that third party application authors simply cannot keep up. Couple that with the desire of the consumers to not have their chosen platform discounted, and if you provide Debian packages, you end up needing to provide for Fedora, RHEL, SuSE, SLES, CentOS, Mint, Gentoo, Arch, etc.etc; let alone supporting all the various BSDs. This leads to the simple expedience of curl | sudo bash -.

Nobody, not even those who are most vehemently against this mechanism of installing software, can claim that it is not quick, simple for users, easy to copy/paste out of a web-page, and leaves all the icky complexity of sorting things out up to a script which the computer can run, rather than the nascent user of the software in question. As a result, many varieties of software have ended up using this as a simple installation mechanism, from games to orchestration frameworks - everyone can acknowledge how easy it is to use.

Now, some providers are wising up a little and ensuring that the url you are curling is at least an https:// one. Some even omit the sudo from the copy/paste space and have it in the script, allowing them to display some basic information and prompting the user that this will occur as root before going ahead and elevating. All of these myriad little tweaks to the fundamental idea improve matters but are ultimately just putting lipstick on a fairly sad looking pig.

So, what can be done? Well we (again the OS-development literati) got ourselves into this horrendous mess, so it's up to us to get ourselves back out. We're all too entrenched in our chosen packaging methodologies, processes, and policies, to back out of those; yet we're clearly not properly servicing a non-trivial segment of our userbase. We need to do better. Not everyone who currently honours a curl | sudo bash - is capable of understanding why it's such a bad idea to do so. Some education may reduce that number but it will never eliminate it.

For a long time I advocated a switch to wget && review && sudo ./script approach instead, but the above comment, about people who don't understand why it might be a bad idea, really applies to show how few of those users would even be capable of starting to review a script they downloaded, let alone able to usefully judge for themselves if it is really safe to run. Instead we need something better, something collaborative, something capable of solving the accessibility issues which led to the curl | sudo bash - revolt in the first place.


I don't pretend to know what that solution might be, and I don't pretend to think I might be the one to come up with it, but I can hilight a few things I think we'll need to solve to get there:

  1. Any solution to this problem must be as easy as curl | sudo bash - or easier. This might mean a particular URI format which can have os-specific ways to handle standardised inputs, or it might mean a pervasive tool which does something like that.
  2. Any solution must do its best to securely acquire the content the user actually wanted. This means things like validating SSL certificates, presenting information to the user which a layman stands a chance of evaluating to decide if the content is likely to be what they wanted, and then acting smoothly and cleanly to get that content onto the user's system.
  3. Any solution should not introduce complex file formats or reliance on any particular implementation of a tool. Ideally it would be as easy to implement the solution on FreeBSD in shell, or on Ubuntu as whizzy 3D GUIs written in Haskell. (modulo the pain of working in shell of course)
  4. The solution must be arrived at in a multi-partisan way. For such a mechanism to be as usefully pervasive as curl | sudo bash - as many platforms as possible need to get involved. This means not only Debian, Ubuntu, Fedora and SuSE; but also Arch, FreeBSD, NetBSD, CentOS etc. Maybe even the OpenSolaris/Illumos people need to get involved.

Given the above, no solution can be "just get all the apps developers to learn how to package software for all the OS distributions they want their app to run on" since that way madness lies.

I'm sure there are other minor, and major, requirements on any useful solution but the simple fact of the matter is that until and unless we have something which at least meets the above, we will never be rid of curl | sudo bash - :- just like we can never seem to be rid of that one odd person at the party, noone knows who invited them, and noone wants to tell them to leave because they do fill a needed role, but noone really seems to like.

Until then, let's suck it up and while we might not like it, let's just let people keep on curl | sudo bash -ing until someone gets hurt.


P.S. I hate curl | sudo bash - for the record.

comment 1

Very, very well said.

So where's the discussion forum where this is going to happen?

For the record, distributing packages without a repository isn't any safer (as I understand the matter). sudo rpm -i ... (or dpkg -i) runs installation scripts after all. Packages have two, potentially three advantages: they are easy to uninstall, they may allow easy dependency handling, and if retrieved from a trusted source via a trusted mechanism there is some security benefit.

Comment by Diggory
0install

"particular URI format"
this instantly made me thing of Zero Install. http://0install.net/ How does it hold up against your goals?

  1. Yes, at least for the end user.
  2. Yes.
  3. No.
  4. Maybe?
Comment by Laverne Schrock
Perhaps you're attacking the wrong problem?

What if the problem isn't the mechanism, but the potential for damage/theft/etc.?

Some clever combination of LXC/Appamor could probably work wonders. It could have an overlay where it could install anything it liked, but not read anything of consequence without the user's consent.

wrap-in-lxc-and-apparmor <url>

Same url as you'd have passed to curl, but wrap-in-lxc-and-apparmor looks at the url to see if it already has a container for it. If it doesn't, it creates it and runs bash inside the container.

Comment by soren
sandboxing

I agree. sad state of affairs. See also: Docker

I'm hopeful about application sandboxing as a way of solving this problem for certain types of software. GNOME are doing some good work there (although quite incomplete): http://gnome.org/Projects/SandboxedApps

For system-level software the problem is a lot more intractable, but if distros can stop caring about having to package 3rd-party apps that only interface with the host machine in well-defined ways, it's a step forward.

Comment by samthursfield
Disagree :)

You're ignoring language ecosystems in your analysis of ease of use and user experience.

There are many things installed via e.g. 'pip install THING' or 'npm install THING' - and they are much better than curlsh precisely because they provide centralised points for dealing with platform quirks, rather than every vendor learning the same lessons. Yes, dpkg can do that.... in the Debian ecosystem,etc. Language centric package managers fill much the same spot but are cross platform by their very nature.

On the review thing - I think you have to either trust or not trust your vendor, and work from there. If you do trust them, there are obviously other boxes to tick - have you got their code or something someone else created. And maybe you don't trust them with root :).

Comment by lifeless
Verifiable content

It seems that if the script being curled could be verified (beyond just https) then it would solve most problems you outlined.

That is exactly what notary appears to solve. (there may be other similar tools)

With verifiable content (via cryptographic signatures) The curl command doesn't get much harder but becomes immensely more trusted assuming you trust the author. Which you are planning on running the software so we can assume you trust them. The new command would be something like.

curl http://runme.sh | notary author/project | sudo bash -

This will check the content curled to verify it has been unmodified from what the author signed.

Comment by rothgar