path: root/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
diff options
authorDaniel Silverstone <>2015-06-10 21:08:57 (GMT)
committer Daniel Silverstone <>2015-06-10 21:08:57 (GMT)
commitc5b2ce7c647d833d884abdd459fb7c7a710815e6 (patch)
tree87d4578d9171a45a501f8b347e91e27f0aadfb7f /posts/in-defence-of-curl-pipe-sudo-bash.mdwn
parent5ec0e53b87b91505052af9a34362e8b4a51e8496 (diff)
Some more tweaks
Diffstat (limited to 'posts/in-defence-of-curl-pipe-sudo-bash.mdwn')
1 files changed, 11 insertions, 9 deletions
diff --git a/posts/in-defence-of-curl-pipe-sudo-bash.mdwn b/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
index fc92293..95fbee7 100644
--- a/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
+++ b/posts/in-defence-of-curl-pipe-sudo-bash.mdwn
@@ -24,21 +24,21 @@ 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 -`.
+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
+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.
+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
`curl`ing 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
+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.
@@ -49,18 +49,20 @@ 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.
+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
+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: