Hacker News Reader

Comment by cjbprime | Hacker News Reader

Very cool.

One benefit of schemes like this that people don't talk about much is that, by no longer downloading from an expected place, you're removing the possibility for a compromised developer or server operator to selectively serve up malware to a targeted user. Instead you're getting the file over bittorrent and checking its hash, and you could gossip with other bittorrent clients to confirm that everyone's trying to get the same hash.

Compare with the state of the art in most software updates, which is that you connect to some download server and it could serve signed malware to people on its target list and probably no-one would notice.

(Schemes that use some of these techniques to take out the single point of malware-insertion have been called "Binary Transparency" schemes, as an analog to Certificate Transparency.)

View on HN

Guix has a very good complementary approach to this problem, guix challenge. Perhaps it's also implemented in Nix too already:

https://www.gnu.org/software/guix/manual/html_node/Invoking-...

Basically, since builds are reproducible, you can automatically build from source and see if the hash of the binary you built matches the one you are downloading.

Obviously, source can be still compromised. But that's probably something IPFS won't fix unless wherever you get sources from is also on IPFS.

`nix-build` can take `--check` to do a similar thing. However, not all packages are reproducible. We've been doing a bit of work on this: https://garbas.si/2016/reproducible-builds-summit-in-berlin.... and have begun checking reproducibility in our CI system: http://hydra.nixos.org/jobset/nixos/reproducibility

Just a tiny nitpick, if I may: most builds are reproducible, but not all. Out of ~5000 packages, ~600 are not yet reproducible.

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.

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.

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

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

IPFS doesnt use bittorrent. Its bittorrent like, bitswap, with some "new protocol in town problems".

I wonder why IPFS hasn't been built on top of Bittorrent, so it could reuse some of the existing infrastructure.

For example, everybody hosting a file in IPFS could automatically become a BT seeder for that file. And searching on Pirate Bay for a certail file path / hash could make the file accessible to people who have a BT client but do not (yet) run IPFS on their machine.

Its my impression that bitswap was chosen/made, to have an easier time making "trading strategies" with other peers.

BitTorrent would for that purpose be harder to modify, and claim backwards-compatibility, so I think they went all-in, and bitswap - with pluggable "trading strategies", ie how to decide which peer to share with and how much - how to avoid free-leach and so on. There was a mention of combining ipfs with filecoin - bitswap would make that integration easier.

One could implement an IPFS-BitTorrent bridge. WebTorrent's hybrid peer [1] does something similar.

[1] https://github.com/feross/webtorrent

This kind of backwards compatibility works against network effects for the new protocol though.

Another way to solve this problem is to have binaries signed by a trusted developer/group. Not necessarily better or worse than using decentralization to solve the problem, just another good idea.

Yeah, that works as long as the trusted group aren't themselves coerced into signing targeted malware, or choose to.

That's really no different to the developers choosing to write malicious code into their own product. A little paranoia about the storage and transport of executable data is understandable but if you cannot even trust the company employees not to compromise their own software then you shouldn't be using their products in the first place.

Where your distrust of keys would have more merit is the storage and strength of said keys. Eg If they dont have a strong passphrase and stored on an NFS / CIFS share then one could argue that they're no more secure than a bespoke build script.

If we believed this argument, there would be no need for Certificate Transparency, which understands that CAs can create certs for any domain -- they've got the keys to do it -- but mistrusts their signatures by default and trusts them only to the extent that their signatures (update bundles, in the software analogy) and logged and seen by everyone at the same time.

I think we can do the same thing for software. Why not try?

I get what you're saying but my point is that if you're running executable software from a particular company then you have to trust their staff with regards to deliberate malicious intent. Ergo if you don't trust the software signers from deliberately (whether that be voluntarily of via coercion) signing malicious software then you equally cannot trust the developers from writing in malicious code first hand and thus that being signed either with or without the certificate holders knowledge. If one cannot even trust the developers not to inject malware into their own software then you might as well give up with that company.

Yes there are tools one can run to protect themselves against the aforementioned, eg application firewalls, sandboxing, network firewalls, etc. But at some point you have to trust that Microsoft Office / Firefox / your favourite Linux distro / whatever was built honestly from the outset as software - even with the source code available in the case of OSS - is far too complex to reliably vet before running in production.

The issues with storage and transport (IPFS, HTTPS, etc) is a different matter because they're to protect against external attacks rather than corruption within the company itself. This is where the issue of software signing might fall short. Not because of disreputable people within the business but more because of negligence (eg certificates not being stored securely so attackers can inject malware into the software and then sign it themselves)

So I'm not against criticisms regarding software signing; I just don't agree with your points regarding the motives of the signers. Simply put, if you cannot trust key people within a business to write and release software honestly (negligence aside), then you should not be installing nor running their software to be begin with.

Reply on news.ycombinator.com