4 ms·

What if there're huge number of rogue builders?

by asdz 10y ago

anilgulecha 10y ago
The only solution is to not use external builders then. But given this is a "community" project, I doubt they can currently bear the cost for fully internal build hosts.
kilburn 10y ago
You cannot get 100% guarantees, just like you can't even with centralized builds (what if your build servers get hacked?). However, you can devise many schemes to improve the probability of builds being correct. For instance, some kind of "trust tracking system": 1. You own one builder, which is the only initially trusted source. This is required to bootstrap the system. 2. You distribute build requests and collect the resulting builds. Whenever a builder's build agrees with your trusted source build, that builder gets "trust points" (up to some max_trust). 3. Whenever two builder's builds don't agree, you build that yourself and compare. The rogue one loses trust points (or gets banned). You can even retroactively check all other builds from that builder if the requirements are stringent enough. 4. A build's trust is the sum of all the builder's trust points that generated that exact same build from the same request. 5. You require k times max_trust trust from a built artifact to consider it valid. Of course, builders wouldn't know against which other builders will they be compared. This doesn't make collusion impossible, but raises the bar significantly because tampering a build when there's a non-colluding builder involved will get you flagged. Going further, it even allows for completely segregated systems to track trust separately. That is, if builders emit signed hashes of their build results, anyone can keep track of which builders he/she trusts without the need for a central authority doing so (in a blockchain-y kind of way). This way you could even have good protection against the "trust authority" itself being hijacked. I would say that such a system, once well tuned, would be even more reliable than using single-company tightly-controlled build servers that can be silently hacked. In any case, it would surely be more trustworthy than just signing up a few builders that you blindly trust, which seems to be the path taken here...
- kilburn 10y ago
  Followup: I suspected that this problem should have been studied in the academic literature. Indeed it is, and this seems to be a good starting point to read about it, if anyone is interested: Sabotage-tolerance and trust management in desktop grid computing http://estudogeral.sib.uc.pt/jspui/bitstream/10316/4095/1/file608a385c50234adaa56526c950cb8332.pdf http://estudogeral.sib.uc.pt/jspui/bitstream/10316/4095/1/fi...

What if there're huge number of rogue builders?

by asdz 10y ago

What if there're huge number of rogue builders?

The only solution is to not use external builders then. But given this is a "community" project, I doubt they can currently bear the cost for fully internal build hosts.

kilburn 10y ago

You cannot get 100% guarantees, just like you can't even with centralized builds (what if your build servers get hacked?). However, you can devise many schemes to improve the probability of builds being correct. For instance, some kind of "trust tracking system": 1. You own one builder, which is the only initially trusted source. This is required to bootstrap the system. 2. You distribute build requests and collect the resulting builds. Whenever a builder's build agrees with your trusted source build, that builder gets "trust points" (up to some max_trust). 3. Whenever two builder's builds don't agree, you build that yourself and compare. The rogue one loses trust points (or gets banned). You can even retroactively check all other builds from that builder if the requirements are stringent enough. 4. A build's trust is the sum of all the builder's trust points that generated that exact same build from the same request. 5. You require k times max_trust trust from a built artifact to consider it valid. Of course, builders wouldn't know against which other builders will they be compared. This doesn't make collusion impossible, but raises the bar significantly because tampering a build when there's a non-colluding builder involved will get you flagged. Going further, it even allows for completely segregated systems to track trust separately. That is, if builders emit signed hashes of their build results, anyone can keep track of which builders he/she trusts without the need for a central authority doing so (in a blockchain-y kind of way). This way you could even have good protection against the "trust authority" itself being hijacked. I would say that such a system, once well tuned, would be even more reliable than using single-company tightly-controlled build servers that can be silently hacked. In any case, it would surely be more trustworthy than just signing up a few builders that you blindly trust, which seems to be the path taken here...

kilburn 10y ago
Followup: I suspected that this problem should have been studied in the academic literature. Indeed it is, and this seems to be a good starting point to read about it, if anyone is interested: Sabotage-tolerance and trust management in desktop grid computing http://estudogeral.sib.uc.pt/jspui/bitstream/10316/4095/1/file608a385c50234adaa56526c950cb8332.pdf http://estudogeral.sib.uc.pt/jspui/bitstream/10316/4095/1/fi...