P2P Packaging/Koji Cloud

[Toshio Kuratomi]

On Wed, Dec 07, 2011 at 03:25:18PM -0800, Adam Williamson wrote:
> On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
> > On Wed, 07 Dec 2011 13:25:28 -0800
> > Adam Williamson <awilliam at redhat.com> wrote:
> > 
> > > 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.
> > 
> > I don't think you understand - we need to be able to reliably reproduce
> > them- sure - but we cannot count on them anymore than we do now. Ie:
> > someone sends an arbitrary pkg with arbitrary repos to supply its
> > buildreqs - we cannot trust the pkg at all.
> > 
> > That's ALWAYS true.
> > 
> > but we definitely cannot allow the above to build on our existing build
> > boxes.
> > 
> >  
> > > 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.
> > 
> > And again - if you are testing your own pkgs - you'll be fine - there's
> > no insecurity there.
> > 
> > You trust you.
> > 
> > and the trust of the images you're building from is up to which cloud
> > service provider you have a contractual relationship with.
> > 
> > 
> > > 
> > > So it occurs to me that if we have a hilariously insecure system for
> > > doing scratch builds, and someone really wants to do evil things to
> > > Fedora, it's going to make their lives a lot easier.
> > 
> > I don't think you understand where the insecurity is in the system.
> > 
> > 
> > > All they have to
> > > do is compromise a provenpackager's scratch build to include some
> > > kind of trojan, then when the provenpackager installs the scratch
> > > build they just fired off, hey presto, the attacker has now
> > > effectively gained provenpackager privileges. They can just hack into
> > > the provenpackager's system using the back door they just trojaned in
> > > there and go about making their nefarious changes to Fedora just as
> > > if they were the trusted packager; they don't need to attack
> > > 'important' builds in-flight any more.
> > > 
> > > Let's put it this way - if we put such a system in place I'd damn well
> > > be doing my scratch builds locally from then on. I wouldn't trust them
> > > to Joe Q. Random's VM.
> > 
> > No one has EVER seriously considered a random person's VM.
> > 
> > ever.
> > 
> > but I do think a vm you create at ec2 or rax or wherever is just fine.
> > 
> > b/c YOU create it with a known good/trusted img as the base.
> > 
> > 
> > do you understand now?
> 
> Well, yes, but only because you shifted the entire terms of the thread
> without telling anyone else. All of the above - about how the idea was
> to build packages with untrusted build dependencies in trustworthy
> places - may have been perfectly clear _to you_, but it was not the idea
> that started this thread. This thread was specifically about creating a
> 'cloud', containing random contributor's machines, for doing builds, and
> several people suggested that might be 'safe' for scratch builds but not
> for 'release' builds.
> 
To be fair, if you read the thread again, I think you'll see that Seth *is*
consistently arguing against using random contributor's machines and for
building on trusted clouds.  And as the other major participant in the
thread (the original poster being the first; seth being the other due to
having replied to pretty much all branches of the thread) he forms the
counterweight to the original position.

Perhaps it's just that I work with Seth and so I read threads where he
participates with an eye towards what he says that that seemed clear to me
so take it for what it's worth but that's how I've perceived the thread so
far.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111207/21641d9f/attachment.bin