launchpad-dev team mailing list archive

[William Grant <me@xxxxxxxxxxxxxxxxxx>]

On Wed, 2009-11-18 at 21:59 +0000, Julian Edwards wrote:
> William Grant wrote:
> > Rather than something strange like this, why not allow the SPN to be
> > created at recipe-registration time? That seems substantially cleaner,
> > and it's not as if the SPN namespace is exactly clean even now.
> 
> It won't work because it needs to traverse through a
> DistributionSourcePackage object.  Just creating the SPN is not nearly
> enough.

The DSP exists as soon as the SPN does. I can traverse and add branches
(eg. for PPAs), but not file bugs unless there are SPRs published in a
distro archive.

> >> Presumably we'll need a buildd-slave SSH key that can access everything?
> > 
> > That's impossible, unless you start doing stuff outside the VM. That
> 
> That was the idea.

Having the host push files into the guest sounds difficult and messy,
but I guess that would work. Although I don't know exactly how
bzr-builder works, mightn't it need to run untrusted code to do stuff
with branches? I'm not entirely clear on what it does.

> > sounds like a recipe for trouble. In a later email, you suggested
> > chroots. chroots do not help. They are simple to break out of.
> 
> Yes, but we cannot arrive at a sensible solution without considering all
> the alternatives.
> 
> > The only solution that I see as feasible is doing something rather like
> > P3As: HTTPS with per-branch credentials. I initially considered that
> > buildd-manager should grant and revoke these credentials on a per-job
> > basis, but I guess a branch's buildd key doesn't ever actually need to
> > change.
> 
> Yes I was trying to think of something comparable to the way we do P3As.
> 
> We could also have a private branch server inside the DC that has no
> restrictions.  I don't really know enough about how that stuff works so
> I'm really happy to have someone that does just come up with a solution ;)

If there is a way for the VMs to push the branches into the guests, then
something open sounds fine. But having an internal basic authed bzr
server still sounds like the best option to me. Hopefully others have
substantially better ideas.

> > Where will they be signed? It cannot be anywhere on the slaves.
> 
> Can you expand on this?  I'm sure there's a good reason but it's late
> and my brain hurts.

If the slave has the key, Bad Things are going to happen when people
steal the keys.

Unless you are talking about doing more things outside the VM, but I
really don't like that idea too much.

> > Remember
> > that we already have lots of unsigned sources in LP (mostly syncs), and
> > that hasn't been much of a problem.
> 
> Indeed, but if we can easily come up with a solution to sign these then
> we should do it!

True.