Running something is as easy as hijacking one of those “copy and paste this line into your command prompt to install this package” things you see on many open source sites. The command always curls some bigger script down and executes it. Often times it even has you sudo to root.
While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it doesn't truly help in terms of security or side-effects as it can still run scripts, so although ultimately the issue is still running binaries not vetted by your distro's maintainers)
> I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well.
They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
When you set your CI/CD pipeline, creating packages, signing them and updating your repositories are all trivial tasks (been there, done that).
In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise.
If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
Actually it's not hard at all. All you need is a half-working build system and tar installed. You just create an additional build target and you're fine.
If you maintain the repository yourself now your setup instruction involves adding a custom apt repo, and then the installation. You also now have to handle multiple package managers, etc. A simple bootstrap script is pretty much as easy as it gets.
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs.
Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
> curl into sh is just as safe as any other software installation mechanism
It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.
But, we’re talking about installing software from non-distribution sources. E.g. the Minecraft Launcher ships as a .deb that you install: there’s no benefit security-wise for that over curl … | sh
And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
curl'ing is not the same at all as running, say, a Debian apt-get install.
You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered.
When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call.
Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well:
# rpm -q --scripts bash
postinstall scriptlet (using <lua>):
nl = '\n'
sh = '/bin/sh'..nl
bash = '/bin/bash'..nl
f = io.open('/etc/shells', 'a+')
if f then
local shells = nl..f:read('*all')..nl
if not shells:find(nl..sh) then f:write(sh) end
if not shells:find(nl..bash) then f:write(bash) end
f:close()
end
postuninstall scriptlet (using <lua>):
-- Run it only if we are uninstalling
if arg[2] == "0"
then
t={}
for line in io.lines("/etc/shells")
do
if line ~= "/bin/bash" and line ~= "/bin/sh"
then
table.insert(t,line)
end
end
f = io.open("/etc/shells", "w+")
for n,line in pairs(t)
do
f:write(line.."\n")
end
f:close()
end
Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.
I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while since I’ve used RPMs, so my syntax is probably off here):
rpm -ip https://mojang.com/Minecraft-launcher.rpm
Which has all the same problems as curl | sh
The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
> I can also pipe the script into a file and read it
Except then it's not the same idiom. Piping curl to a shell is not the same thing as downloading and running an installer, even if that installer happens to be a shell script. Part of the main problem is that the installation steps are ephemeral. It's nearly impossible to confirm that what was run when you installed it is what you see when you check the installation URL now, where now may be a week, a month or a year later.
> Which has all the same problems as curl | sh
No, I just god through outlining some of the ways it specifically is different in the prior comment. At a minimum, you know what launcher was installed, and what URL it's set to check, and what version it is in case there's a bug in the launcher. It shares some problems with piping an online script to a shell, but not all of them. You may think the ways in which they differ don't matter, but that's an opinion, and I hold a different one. They are different in real ways though.
You are right. Adding third-party PPAs is not secure (it is because Linux distributions are not friendly to third-party software), that's why it is always better to download and unpack such software manually without running it as root.
White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS.
I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy.
Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
You say that like doing so is a negative thing. How do you think executable code gets on a system in the first place?
Either an Admin builds from source, an Admin installs a binary from a source they deem trustworthy, or you YOLO, download something sketchy to an older system and watch what your Network Analyzer/reverse engineering stack spits out.
App stores changed none of that in terms of fundamental activity one needs to do. They just lull users into a false sense of security because "someone else did it". I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
> App stores changed none of that in terms of fundamental activity one needs to do.
This just isn’t true: app stores vary but they added some key changes — developers have a reputation to worry about, stores restrict what APIs you can call, and it provides a single place to force updates or pull malware. That’s not perfect, of course, but it’s better than just installing whatever you find online — Facebook et al. wouldn’t be upset with Apple if it wasn’t working.
> I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
Reminds me of early days in my career when my mentor and I were discussing user issues with a library we maintained. I didn't realize it at the time, but he was messing with me by suggesting we add some hooks to report usage statistics back to us and use that to improve things.
I was young and naive so excuse that I got really excited at the genius of the idea. If not for his wry smile, I would have happily run off and implemented just that.
It's telling that you got grayed out that fast for what I don't think is an uncommon programming life lesson to try to instill.
What people run on their machine is no one's business but theirs. Undisclosed/non-consensual information leakage is unethical, and immoral. Period. I'm also not entirely on the status-quo of "accept the EULA or F off" form of disclosure or consent facilitation either. If someone reaches out, by all means, get the detailed info you need, but don't pull it. Let them push it. Other folk's machines don't become yours by virtue of executing some version of a computation you wrote once, no matter how badly Microsoft, IBM, Intel, and the FAANG's wish that were the case.
Note, this would be considered anti-thetical to most corporate or for-profit interests in the computing space; so don't be surprised if you get blowback or static for it.
“Trust” is something you can give, though, as long as it’s not to the whole world.
Do you trust the Debian project? I mean, there’s reasons to trust them but if you don’t, then don’t run Debian.
If you do: the package repositories carry their chain of trust, since they’re signed by Debian maintainers- not the application developers themselves.
That’s a large distinction.
App stores didn’t give us trust; they have developers direct access to users and, crucially, the ability to charge for software- which was not a consideration for package managers before.
And Apple for the most part has been trying to carry the “burden” of ensuring trust, at a high cost.
Or just copying a command with a hidden `<span>` in the middle, then pasting it into a terminal which allows multiline pastes (which most terminals do).
While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).