What we need is for the blog to explain things as nicely as the GitHub repo does - unfortunately, it's a topic that's a bit hard to concisely explain in one line.
Maybe they added it after you read it, but when I read the post they specifically mention it's bad and provide a link to read more on why it's bad.
Sure an alternative would be great but the point of the article is to get up and running with the pi-hole software so they went with the fastest install.
The more realistic fear is what happens if your connection goes away mid-download. While a partial binary won't run, a partial shell script will, and it might just do something bad to your system if you're unlucky.[1]
That said, the chances of your connection crapping out in the second or two it takes to download the average sub-couple-kilobyte shell script is minuscule. The fear is seriously overblown.
I reckon the biggest problem is normalising the pattern.
Piping (https) curl to shell from a site who you were going to trust and download software/run from if they had an alternative method anyway - is no less secure than downloading a tarball or .dmg from the same site.
Getting into the habit of piping curl to shell is a bad idea though. It's gonna be easier when you're in a rush to not notice you're copy-pasting "curl -sSL https://install.pi-hole.ru | bash" from some "helpful" forum post...
I’m not sure why Pi Hole doesn’t even maintain a Raspbian apt repo; I’m guessing at least 95% of users use it since it’s the ‘default’ OS for the Pi. Failing that, Debian itself.
Where the hell did this argument come from? “If you don’t personally inspect your .deb you might as well be piping curl | sh?”
You can sign a .deb, there’s a whole infrastructure around distributing PGP keys for repos, and plenty of us do examine .deb file from strange places before installing them (like ok, this package runs a service but with appropriately restricted privileges, or that package just has data in it, and yes, some of us examine the source). And when someone distributes a bad .deb we have the ability to put together the package and its signature to get basically a smoking gun that person X is compromised and their key should be revoked immediately. The thing is, with a .deb you don't actually have to detect everything ahead of time you can archive the .deb and figure out what happened after you get pwned.
With curl | sh it’s basically impossible. There's no signature, just a bit of TLS at best which is gone to the ether. You can't sign curl | sh and there are some pretty nice attacks which you can use to thwart people who try to read the script sent from the server. I've seen reports of spear phishing attacks sent to otherwise sophisticated developers that use curl | sh as their vector... because curl | sh is fucking perfect for spear phishing. A .deb... is not.
Yes, I absolutely do know people who do this. I know people who accidentally let a GPG key expire and spent some long nights figuring out a way to get the thing trusted again so they could sign .debs, because dammit, THEY sign the .debs not some maintainer somewhere else. I know people who run their own deb mirrors (this is really common! I know SHITLOADS of people with Debian mirrors!). I know people who do everything from control servers that have a minimal set of software, people who run new software in locked down testing servers before wider release. And I know people who are Debian maintainers who actually do review the code that gets built, even if it's not a line-by-line audit. I know people who compile from source and compare executable checksums to see if it matches the official repo, ever since reproducible builds is a thing.
Some of these people are crazy because they're paid to be crazy by a software firm. Some of these people are too crazy for the software firms, they work as consultants and in their free time they're constantly trying to get firmware dumps of their game consoles, phones, and laptops.
And yes, a bunch of these people are on your side. But if you curl | sh it's harder for anyone to help you, including yourself, when shit goes south.
> Someone actually reviewing the source code is in a different category entirely, they don't need a download at all.
This isn't an all-or-nothing deal. Just because you read the source code for a package doesn't mean that you can't also download the binary. Reproducible builds give you some additional confidence that something weird hasn't been snuck in through a single compromised machine, and additional confidence that the binary package corresponds to the source code even if you didn't personally build it.
Malicious software is also not the only thing you're looking for, but things like unsafe practices in the code or insecure defaults.
In practice I do review source code from time to time before I install something, and sometimes I decide not to install it after looking at the source.
> Practically speaking the TLS bit is the important thing. Your package signature doesn't offer more in practice.
No, actually, the signing bit is important. You can MITM TLS, and it's easy to miss it if you are not verifying that the cert is from the host you expect it to be from. Meanwhile, the only way signing can be compromised is if the maintainer loses their private key. That's not unheard of, but is much harder/rarer.
Signing says "craftyguy created this package". TLS says "This script comes from pi-hole.net (which only pi-hole approved admins have access to".
The difference is marginal and uninteresting.
Sure, if you don't care about non-signed or self-signed certificates, then you've got a problem. But that's just the same as not verifying a package signature.
The key piece is whether curl performs hostname verification of the cert, or not. Their ssl certs page is unclear[0] (they go off into the weeds about self-signed certs). If they are not verifying the hostname, then your argument is completely off base since it's basically "you trust a person who signed a thing" vs "you trust a thing you got from someone who has a cert that is trusted by a CA on your system" (and that's pretty trivial to get considering how many 'trusted' CAs distros/OSes ship by default).
In practice the difference is real. Web servers are much more difficult to secure than package signing keys. Imagine, for example, someone gets kicked out of the project and people forget to revoke the developer's SSH key. Or imagine social engineering attacks against the hosting provider. Or think about teams that run outdated and vulnerable blog software on the same server that hosts their curl|sh script.
The difference ends up being substantial once you look at typical web hosting infrastructure. There's a reason why people don't copy code signing keys to their web server.
But, it is known that there are state-level actors which can forge certificates (because they can coerce CAs). This has happened. You may take a moment to consider whether state-level actors are part of your threat model (and not everyone has an answer to that which they like).
I'm not saying that curl|sh is the golden standard for software deployment.
But the choice is not really between "curl|sh pi-hole" and "pi-hole in a well-known package archive, with signature". It's "curl|sh pi-hole or no pi-hole at all".
I just feel triggered by this security absolutism where everything is shit, and unless you're doing an offline multi-way key generation with subsequent physical destruction of the equipment used, you should just shut up and not release software.
I'm not entirely sure what you mean here, are you poking fun at people who put state-level actors in their threat models? Because for some of us, the choice is between ignoring attacks from state-level actors and figuring out ways to mitigate the attacks, there is no third option where the state-level actors do not attack us.
> I just feel triggered by this security absolutism where everything is shit, and unless you're doing an offline multi-way key generation with subsequent physical destruction of the equipment used, you should just shut up and not release software.
Honestly? I feel you've described my complaints with your argument. Security is a matter of degrees, threat models, evaluating likelihoods and potential severity of attacks, weighing the cost of prevention against the cost and likelihood of a successful attack.
The fact is that curl|sh has a lot of problems that a .deb and src .deb signed by some random developer's key doesn't have. It's not some kind of black-and-white world where curl|sh is inexcusable, it's just a world where on the sliding scale of security versus convenience, some of us think curl|sh is just a little too insecure for what little convenience it provides. I would get a headache trying to write the kind of shell script that makes a cross-distro curl|sh work at all.
> But the choice is not really between "curl|sh pi-hole" and "pi-hole in a well-known package archive, with signature". It's "curl|sh pi-hole or no pi-hole at all".
The third choice is to clone the Pi Hole repository from GitHub and build that.
> And the "smoking gun" part is something nobody cares about. By then their systems are compromised.
This is such an obvious falsehood I'm surprised we're even discussing it here. Security is a mix of prevention and detection. The ability to do forensics on compromised systems is important. Sure, it would be better if we could not compromise our systems in the first place but we don't live in some kind of bizarro binary world where if you have a compromised system you have to curl up and die. Life goes on after your system is compromised and it's better to have more information about attack vectors than less.
And realistically speaking, what happens here is some developer's credentials get compromised, the bad .deb gets uploaded somewhere with a good signature, people freak out about it, maybe the developer issues a key revocation, things improve. If you are curl|sh it's that much more difficult.
The problem is that curl|bash isn't authenticated, I don't really know whether the executable I'm getting was really built by the maintainer or if a malicious attacker was able to sneak in and replace it (like what happened with eslint a few weeks ago[1]). Passing off a signed package (as .debs are) as genuine requires getting a hold of the signing key as well, which increases the difficulty of the compromise.
No, it doesn't. We're not talking about the Debian package archive.
We're realistically talking about the hypothetical where a .deb is sitting on pi-hole.net, with a GnuPG key right next to it and instructions to trust this key.
