On Thu, 08 Dec 2011 04:34:57 +0900
夜神 岩男 <supergiantpotato@xxxxxxxxxxx> wrote:
> 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"
Bandwidth is the big concern for the end user here and then the other
issue is - is all of this worth it for building pkgs? I don't think it
is, personally, pkg building is not that huge of a hit, afaict to
getting things done.
I mean the sum total of the steps were talking about, even now is more
or less:
1. init host
2. stuff some files onto it
3. start up a process
4. communicate to that process
5. build pkg
6. stuff pkgs into a local repo
7. go to 5 until no more pkgs
8. download all pkgs back to original client
9. destroy host.
you can do it now if you're willing to do steps 5-8 manually.
-sv
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
