[m3ta]

Sorry, I don't understand. If the problem is a hypothetical situation where a compromised developer uploads malicious code, then how does IPFS relieve any pressure from that circumstance?

Individual IPFS nodes are certainly blindly trusting the developer's signature as a stamp of approval. Adding more nodes doesn't make that problem better. It makes it worse by providing a greater false sense of security.

In the case of a compromised server operator, as long as hosting company X is smaller than Amazon, it's always better to use Amazon's cloud service to mitigate the possibility of server operator tampering.

[icebraining]

I think the point is that you can't serve a malicious version to a specific user, you must serve it to everyone, which makes it much easier to detect.

[hueving]

It makes targeted attacks more difficult because you have to compromise all of your users rather than offer a different download to one.

[nbadg]

Agreed. I think it only makes sense to say it offers tamper protection if you have reproducible builds and are distributing the source code via (for example) IPFS. But even that is then questionable, because who's auditing the source code? Or the builds? Or the compiler?

Trust isn't really something you can algorithmically fabricate. At a certain point it always reduces to a tautology: "I trust this thing because I trust it." Distributed compiled code, because of its opacity and complexity, is an excellent example of exactly how hard it is to kick that bootstrapping tautology further down the road.

Distributing binaries via IPFS is functionally identical to distributing signed binaries from a central server, provided clients always check the signature. Now, that last bit isn't necessarily always true, but if your problem is "why aren't my clients checking their signatures", solving it with IPFS just doesn't make sense. It's like saying "This person isn't PGP signing their emails, so I'm going to download all of my emails using Bittorrent."