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.
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).