3 ms·
Where you download it from and SHA only gives guarantees about integrity of the data transfer. I am talking about trusting that the code does what it is suppose
by andreasvc 12y ago
Where you download it from and SHA only gives guarantees about integrity of the data transfer. I am talking about trusting that the code does what it is supposed to do. Bugs can hide in code for years, whether inserted accidentally or intentionally, as the Heartbleed episode demonstrates. SHA does absolutely nothing against this.
- skj 12y agoI'm addressing malice, not oversight. The SHA allows you to be confident that you've got the same code as everyone else.
- andreasvc 12y agoI was addressing malice as well. Having the same code is no guarantee that it does not contain an intentional bug that can be exploited. Neither is knowing that it came from some specific entitity (code signing), because again this presupposes establishing trust. There is no technical solution to trust.
- skj 12y agoBut if the code you have is the same as the code millions of other people have, it's safer to give it the benefit of the doubt than a single server than only a handful of people have access to.
- andreasvc 12y agoI just gave you an example where it turned out not to be safer: Heartbleed. Malicious bugs can be well hidden, also in open source code. The openness shouldn't give you a false sense of security, because it doesn't imply the code has been audited any better than some closed source code.
- skj 12y agoI disagree that heartbleed is an example of not being safer. If everyone's SSL was a closed-source library, then we would be considerably less safe. But to carry the analogy to a closed-source web site that you just connect to, as is the topic of this comment thread, we'd certainly be less safe if we routed all SSL traffic through an unknown system on the web that had the opportunity to decrypt and encrypt.