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
possible.
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@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"
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
