P2P Packaging/Koji Cloud

Adam Williamson awilliam at redhat.com
Wed Dec 7 23:25:18 UTC 2011

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.

You seem to have changed the terms of debate rather considerably with
your _own_ idea, which you introduced into the thread, but which clearly
was not actually very similar at all to the idea of the person who
actually started the thread, Denis Arnaud. The extent of the difference
between what _he_ was thinking/talking about and what _you_ are
thinking/talking about has only been made clear in this last post of

The other thing that's confusing is your use of 'wherever' and
'anywhere' when talking about where the builds take place:

"ec2 or rax or wherever"
"scratch or personal chainbuilds could be built in ec2 or rax or
anywhere w/o an issue"

ec2 or rax, I'm fine with. 'anywhere' or 'wherever', I'm not fine with.
I'm guessing, now you've explained things a bit better, that by
'anywhere' or 'wherever' you really mean 'in any reasonably trustworthy
cloud', but that's not what you actually _said_, nor was that meaning
particularly apparent.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora

More information about the devel mailing list