P2P Packaging/Koji Cloud

夜神 岩男 supergiantpotato at yahoo.co.jp
Wed Dec 7 19:34:57 UTC 2011

An idea just struck me that may work.

If the system is made light enough that it is utterly painless for 
anyone to contribute processing time then cross-checking of hashes could 
be made statistically secure, save for a widespread compromise of the 
entire Fedora userbase.

For example, if I just "yum install skyline"[1] and then set "chkconfig 
skyline on" or whatever the systemd equivalent is (sorry, haven't kept 
up lately) and my system just started pulling packages to build/rebuild 
constantly in the background with a priority level low enough I'd never 
notice it, then overnight Fedora as a project would have FAR more build 
time than it needs.

So how is this secure?

Each time a build is made, the building system makes a hash of the set 
of RPMs in $wherever/mock/result/{foo,bar} and sends the completed data 
back to the Fedora build system.

Now the Fedora build system checks the hash to make sure it is correct. 
Of course it is, because we've only got one sample.

But then we collect the other builds of the same RPM from, say, 10 other 
random systems and compare their hashes to what was received from the 
initial build system.

A has that doesn't match whatever arises as the common hash is either an 
error (likely considering the amount of transmission involved) or 
poisoned. These will stick out like a sore thumb amongst the forest of 
correct builds.

So how would I compromise this system? I would have to poison every 
single SRPM departing the Fedora build infrastructure. Hard, maybe, but 

How do we prevent that? Use SSL to transfer the packages in the first 
place, and now that avenue is not available in the time allotted for the 
attack to proceed.

This system depends chiefly on one thing: Having a boatload of 
contributors. I think we could easily expect 1,000+ active contributors, 
particularly if we make this a happy competition complete with a stats 
tracker the way the BOINC and SETI at Home trackers work. People who send 
more than 1 bad hash could be notified by their system that things 
aren't working out which could be an early warning in identifying 
whether the system is indeed being attacked (or the individual's system 
has been compromised). A throttle based on such indicators could let us 
know to halt the distributed build and switch back to "old koji".

Just some ideas.

1. Sorry, silly package name idea from the image of city construction 
"koji" + "cloud"

More information about the devel mailing list