5 ms·
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 deli
by 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 agoThis 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 agoIt 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 agoThat 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.