3 ms·

I understand. That only moves the problem to where you get the signature from, it doesn't solve it (unless you are using a central repo you already trust for ex

by shawnz 5y ago

I understand. That only moves the problem to where you get the signature from, it doesn't solve it (unless you are using a central repo you already trust for example). Therefore binary packages shipped on a GitHub releases page alongside a signature file still face the same issue. An attacker simply has to replace both the package and the signature with one they control. It is nothing to do with the packaging format being a deb file instead of an install script, the issue applies in either case.

throwaway984393 5y ago
Public key servers. Upload your key to 3 different key servers (keyserver.pgp.com, keyserver.ubuntu.com, pgp.mit.edu). Have the user download it from all 3, verify they're the same, verify the package signature with the public key. People already do essentially this (but from one key server) when they add custom PPAs to a distro. In order to hack that package, someone would have to either A) steal the signing key from the developer's airgapped laptop, or B) hack github.com and 3 independent key servers.
- shawnz 5y ago
  The point is not whether it's a solvable problem. The point is that it's not conventional to go to such extents, no matter what kind of packaging you use. This kind of process could be done with either install scripts or deb/rpm packages with nearly the same level of effort, but nobody conventionally does this kind of thing with either (maybe with the exception of stuff that's in a central repo, where you do get SOME protection by default). So it's wrong to say that install scripts are the cause of the problem. The common pattern of "curl | sh" is just as bad as the common pattern of "download a deb and install it". It's not an improvement to simply shun install scripts without solving the actual trust issue.
  - throwaway984393 5y ago
    Nobody is shunning install scripts. You can still have an install script. Just don't pipe it into bash from curl. This is not like some kind of "normal" software distribution pattern. Every other modern OS in the world has solved the trust issues by either verifying the software is signed, or requiring you click some button that says "I acknowledge that I am about to totally fuck up my PC with this untrusted software". The Linux distros verify package signatures, Windows verifies exe signatures, Macs do too (afaik?), Android and iOS do. Curling to a pipe is just devs being lazy. The trust issues were solved a while ago. Not that devs being lazy is anything new. Literally the only reason anyone can use Linux at all without spending 2 weeks setting it up by hand is because somebody other than the software developers did the hard work of packaging it correctly. The curl|bash pattern is just the `./configure && make && make install` of modern devs. (But even then you could still verify the tarball signature before untarring it)
kortilla 5y ago
No, you don’t get it. Once you have the root of trust you can download new signed packages in perpetuity and know they came from the developer. They can be delivered over http/smpt/telnet/BitTorrent/ftp/whatever. You can literally pull it from a compromised machine with an active attacker and it doesn’t matter. It either has integrity and it’s safe or it fails to install. That’s a huge difference from encouraging people to exec curl statements from random websites loading JavaScript from ad networks, trackers, etc, etc. You’re not only trusting the original dev, you’re now having to trust the web host and all of the other locations the page sources JavaScript from. This is why any systems serious about security used signed packages. There are way too many systems/parties in between that can knowingly or unknowingly comprise https downloads. Windows updates, Linux updates (for the majority of package managers), iOS updates, Android updates, etc. The trust model of “curl | sh” is severely worse than signed packages. They are in no way equivalent.
- shawnz 5y ago
  This only solves the problem of trusting updates, not the initial installation. For new software, "curl | sh" is no different from installing a random deb package from GitHub.
  - kortilla 5y ago
    It solves initial installation too if you trust particular roots. There is a reason windows/android/Linux distros/iOS do signed software. This problem was known about and was solved 20+ years ago with signed updates. “curl | sh” is back in vogue because people don’t understand the problem and think https means secure.
    - shawnz 5y ago
      That is what I mean about it only being better in the limited scenario where you are getting the package from an already-trusted central repo. But that is surely not the case in this particular situation for example.

by shawnz 5y ago

throwaway984393 5y ago

Public key servers. Upload your key to 3 different key servers (keyserver.pgp.com, keyserver.ubuntu.com, pgp.mit.edu). Have the user download it from all 3, verify they're the same, verify the package signature with the public key. People already do essentially this (but from one key server) when they add custom PPAs to a distro. In order to hack that package, someone would have to either A) steal the signing key from the developer's airgapped laptop, or B) hack github.com and 3 independent key servers.

shawnz 5y ago
The point is not whether it's a solvable problem. The point is that it's not conventional to go to such extents, no matter what kind of packaging you use. This kind of process could be done with either install scripts or deb/rpm packages with nearly the same level of effort, but nobody conventionally does this kind of thing with either (maybe with the exception of stuff that's in a central repo, where you do get SOME protection by default). So it's wrong to say that install scripts are the cause of the problem. The common pattern of "curl | sh" is just as bad as the common pattern of "download a deb and install it". It's not an improvement to simply shun install scripts without solving the actual trust issue.
- throwaway984393 5y ago
  Nobody is shunning install scripts. You can still have an install script. Just don't pipe it into bash from curl. This is not like some kind of "normal" software distribution pattern. Every other modern OS in the world has solved the trust issues by either verifying the software is signed, or requiring you click some button that says "I acknowledge that I am about to totally fuck up my PC with this untrusted software". The Linux distros verify package signatures, Windows verifies exe signatures, Macs do too (afaik?), Android and iOS do. Curling to a pipe is just devs being lazy. The trust issues were solved a while ago. Not that devs being lazy is anything new. Literally the only reason anyone can use Linux at all without spending 2 weeks setting it up by hand is because somebody other than the software developers did the hard work of packaging it correctly. The curl|bash pattern is just the `./configure && make && make install` of modern devs. (But even then you could still verify the tarball signature before untarring it)

kortilla 5y ago

No, you don’t get it. Once you have the root of trust you can download new signed packages in perpetuity and know they came from the developer. They can be delivered over http/smpt/telnet/BitTorrent/ftp/whatever. You can literally pull it from a compromised machine with an active attacker and it doesn’t matter. It either has integrity and it’s safe or it fails to install. That’s a huge difference from encouraging people to exec curl statements from random websites loading JavaScript from ad networks, trackers, etc, etc. You’re not only trusting the original dev, you’re now having to trust the web host and all of the other locations the page sources JavaScript from. This is why any systems serious about security used signed packages. There are way too many systems/parties in between that can knowingly or unknowingly comprise https downloads. Windows updates, Linux updates (for the majority of package managers), iOS updates, Android updates, etc. The trust model of “curl | sh” is severely worse than signed packages. They are in no way equivalent.

shawnz 5y ago
This only solves the problem of trusting updates, not the initial installation. For new software, "curl | sh" is no different from installing a random deb package from GitHub.
- kortilla 5y ago
  It solves initial installation too if you trust particular roots. There is a reason windows/android/Linux distros/iOS do signed software. This problem was known about and was solved 20+ years ago with signed updates. “curl | sh” is back in vogue because people don’t understand the problem and think https means secure.
  - shawnz 5y ago
    That is what I mean about it only being better in the limited scenario where you are getting the package from an already-trusted central repo. But that is surely not the case in this particular situation for example.