4 ms·

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

> 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. curl|sh offers 0 verification of authenticity.

Dylan16807 8y ago
Easy to miss? How so?
- klodolph 8y ago
  IIRC, in the past Curl had some bad defaults. 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).
  - Tomte 8y ago
    Yes, that's "security by dramatization". ;-) 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.
    - klodolph 8y ago
      > Yes, that's "security by dramatization". ;-) 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.
Tomte 8y ago
You're wrong. 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.
- craftyguy 8y ago
  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). https://curl.haxx.se/docs/sslcerts.html https://curl.haxx.se/docs/sslcerts.html
- klodolph 8y ago
  > The difference is marginal and uninteresting. 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.
boomlinde 8y ago
Note that it's 'curl', not 'curl -k'

Dylan16807 8y ago

Easy to miss? How so?

klodolph 8y ago
IIRC, in the past Curl had some bad defaults. 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).
- Tomte 8y ago
  Yes, that's "security by dramatization". ;-) 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.
  - klodolph 8y ago
    > Yes, that's "security by dramatization". ;-) 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.

Tomte 8y ago

You're wrong. 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.

craftyguy 8y ago
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). https://curl.haxx.se/docs/sslcerts.html https://curl.haxx.se/docs/sslcerts.html
klodolph 8y ago
> The difference is marginal and uninteresting. 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.

boomlinde 8y ago

Note that it's 'curl', not 'curl -k'