path: root/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
diff options
authorDaniel Silverstone <>2015-06-10 20:47:26 (GMT)
committer Daniel Silverstone <>2015-06-10 20:47:26 (GMT)
commit65e0464c09b6265a8e9630ba48ff610bebcc3803 (patch)
treea658a7e864acb14652628ed90873fcce22360ae2 /posts/in-defence-of-curl-pipe-sudo-bash.mdwn
parent19e8df8f3d4046121ea5d75dd4424568e555bf26 (diff)
update draft
Diffstat (limited to 'posts/in-defence-of-curl-pipe-sudo-bash.mdwn')
1 files changed, 97 insertions, 2 deletions
diff --git a/posts/in-defence-of-curl-pipe-sudo-bash.mdwn b/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
index 9e22c37..2da8b47 100644
--- a/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
+++ b/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
@@ -1,6 +1,101 @@
[[!meta title="In defence of curl | sudo bash -"]]
[[!meta author="Daniel Silverstone"]]
-[[!meta date="2015-06-03 18:00:0)"]]
+[[!meta date="2015-06-10 22:00:00"]]
[[!tag draft]]
-TODO: Write this
+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 (78 gigabytes of source 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.etc. 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 likes how easy it is.
+Now, some providers are wising up a little and ensuring that the url you are
+`curl`ing is at least an `https://` one. Some even omit the `sudo` from the
+copy/paste space and have it in the script, after displaying some basic
+information and prompting the user that this will occur as root. 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. 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
+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 `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 `sudo | bash -` :-
+just like we can never seem to be rid of that one odd person at the party,
+who 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 `sudo | bash -`ing until someone gets hurt.