The install process is curling a script into bash:
curl -sSL https://install.pi-hole.net | bash
curl -sSL https://install.pi-hole.net | bash
That said, if you're a linux admin you shouldn't copy-paste r̼̯ḁ͙̬̕n̪͍̯d̳̦͓̜͉͜o̴̳m̳͚ ̡̭s̜̦̣̠̀h͓̲i̼̫̮̗̜t̜̗̜̪̬̲͟ anyways.
[0] https://brew.sh/
Repo explanation: https://github.com/pi-hole/pi-hole#one-step-automated-instal...
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.
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.
[1]: https://www.seancassidy.me/dont-pipe-to-your-shell.html
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...
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.
It's an edge case at best. If that's the best argument not to curl, there are no good arguments.
I'm in favor of things that noticably help the risk of spear phishing, but are you sure this does?
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.
For people that are highly paranoid downloaders, I'm surprised they're getting software from a website to being with.
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.
With the one liner above its pulling over ssl so at the very least you have some line of trust to the domain you pulled it from.
Exactly. I stand by it.
Practically speaking the TLS bit is the important thing. Your package signature doesn't offer more in practice.
And the "smoking gun" part is something nobody cares about. By then their systems are compromised.
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.
curl|sh offers 0 verification of authenticity.
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.
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.
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.
[1]https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...
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.
I do check for usage figures, project involvement, apparent real name usage and such when considering random apt repos (PPAs).