<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Date: Thu, 08 Dec 2011 04:34:57 +0900<br>
From: 夜神 岩男 <<a href="mailto:supergiantpotato@yahoo.co.jp">supergiantpotato@yahoo.co.jp</a>><br><br>Each time a build is made, the building system makes a hash of the set<br>
of RPMs in $wherever/mock/result/{foo,bar} and sends the completed data<br>
back to the Fedora build system.<br>
[...]<br>This system depends chiefly on one thing: Having a boatload of<br>
contributors. I think we could easily expect 1,000+ active contributors,<br>
particularly if we make this a happy competition complete with a stats<br>
tracker the way the BOINC and SETI@Home trackers work. People who send<br>
more than 1 bad hash could be notified by their system that things<br>
aren't working out which could be an early warning in identifying<br>
whether the system is indeed being attacked (or the individual's system<br>
has been compromised). A throttle based on such indicators could let us<br>
know to halt the distributed build and switch back to "old koji".<br></blockquote><div><br></div><div>I really like the idea of having a build infrastructure the same way SETI@Home provided. It is maybe just a matter of generation (younger developers do not even know what SETI is, I guess)?</div>
<div>It reminds me another related initiative, my trainee and I started two years ago (<a href="http://www.corefarm.org:81/blog/">http://www.corefarm.org:81/blog/</a>), which gave birth to Corefarm (computing grid for 3D image rendering). By the way, the model could be similar to that of Corefarm: one version (<a href="http://www.corefarm.com">http://www.corefarm.com/</a>) using some "safe" Amazon EC2 and/or RedHat/Fedora trusted clouds; another version <a href="http://www.corefarm.org">http://www.corefarm.org</a>, community-based, for building personal scratch builds.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">1. Sorry, silly package name idea from the image of city construction "koji" + "cloud"<br>
</blockquote><div><br></div><div>Skyline is just fine :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Date: Wed, 07 Dec 2011 15:02:42 -0500<br>
From: Przemek Klosowski <<a href="mailto:przemek.klosowski@nist.gov">przemek.klosowski@nist.gov</a>><br><br>
I'd say we need to be paranoid on this one and consider a tainted kernel where your own binaries would report A-OK on a rigged gcc because kernel has a special case for it. Test builds and QA might be OK, but nothing that results in shipped bits.<br>
</blockquote><div><br></div><div>It reminds me of the back-door introduced by Ken Thompson (<a href="http://cm.bell-labs.com/who/ken/trust.html">http://cm.bell-labs.com/who/ken/trust.html</a>), and having lived a long way before being eventually disclosed by its author.</div>
<div>Hmm... when we moreover add Adam's objection (that someone could tap into a proven-packager's flow, and then tamper any package on the central Fedora repository) on top of it, the security issue does not appear that much easy to alleviate :(</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Date: Thu, 08 Dec 2011 05:35:02 +0900<br>
From: 夜神 岩男 <<a href="mailto:supergiantpotato@yahoo.co.jp">supergiantpotato@yahoo.co.jp</a>><br><br>
I think you are correct in essentially asking if this is a solution in search of a problem.<br></blockquote><div><br></div><div>Let me try to state my use case.</div><div>1. I would like to be able to throw chain builds (for one of my upstream projects, there are something like 15 components to be rebuilt one after the other) and mass rebuilds (for instance, when Boost is upgraded, i.e., every Fedora release) on some dedicated buildroots and/or with some specific tags. I know that Koji already allows to do that.</div>
<div>2. I would like to be able to throw those build requests from anywhere, including behind corporate firewalls. And, here, Koji is not (yet?) able to do that.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
While it is very possible to do something like this, and the idea is exciting because it is something new, I've never heard of anyone kicking and screaming about a wait queue bottleneck or insufficient resources in the Fedora infrastructure.</blockquote>
<div><br></div><div>Yes, security put aside, I believe that it would be very exciting, for a lot of contributors, to participate in that way to Fedora. It would make Fedora unique, as well, among all the Linux distributions. But Fedora does not need to be unique, as it is already the best distribution, isn't it?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Date: Wed, 7 Dec 2011 16:15:56 -0500<br>
From: seth vidal <<a href="mailto:skvidal@fedoraproject.org">skvidal@fedoraproject.org</a>><br>
<br>
So I have two thoughts on this:<br>1. Scratch or personal chainbuilds could be built in ec2 or rax or anywhere w/o an issue<br>2. For our shipping pkgs, building them in the existing koji build-systems and/or in a dedicated private cloud instance makes sense - if only for resource allocation and control.<br>
</blockquote><div><br></div><div>Again, security put aside, it sounds great.</div><div><br></div><div>It would be a very good start, already, to provide a simple way (i.e., a package group like "fedora-cloud-packager"?) to set up, locally and/or on a private cloud, a package build and repository system. All the components are more or less already in Fedora today (Koji server, cloud software stack); it is then a matter of gluing everything together in a consistent manner, so that it becomes easy for any packager to set up and to use.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Date: Wed, 07 Dec 2011 13:25:28 -0800<br>
From: Adam Williamson <<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>><br><br>I'm not sure we can treat scratch / personal builds with *quite* so much abandon. They're still valuable targets for anyone trying to compromise Fedora, after all.<br>
Who uses scratch builds the most? Well, probably Fedora packagers, right? And we probably wind up deploying them on our own systems after we build them. That's what scratch builds are _for_ - testing your stuff before pushing it out more widely.<br>
</blockquote><div><br></div><div>While I tend to agree that this perspective is pretty scaring, I also believe that<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); "> </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">夜神 岩男's ideas could tame that threat, at least a little bit. We could maybe have circles of trust/friends, much like PGP keys are managed and trusted, and much like some P2P networks (e.g., OneSwarm (</span><a href="http://www.oneswarm.org/">http://www.oneswarm.org/</a><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">) and RetroShare (</span><a href="http://retroshare.sourceforge.net/">http://retroshare.sourceforge.net/</a><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">)) are secured.</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); "><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Date: Wed, 7 Dec 2011 12:45:59 -0900<br>
From: Jef Spaleta <<a href="mailto:jspaleta@gmail.com">jspaleta@gmail.com</a>><br><br>I'd also like to see if we can use utility cloud resources to efficiently scale out a mass rebuild on demand and perform self-hosting test runs or failure to build runs on a regular scheduled basis. Something we can do in a well managed utility cloud I would think without slowing down day to day packaging work.<br>
</blockquote><div><br></div><div>For instance, we could build more frequently specific spins, and multiply their number.</div><div><br></div><div><br></div><div>Regards</div><div><br></div><div>Denis</div><div><br></div>
</div>