launchpad-dev team mailing list archive

[William Grant <me@xxxxxxxxxxxxxxxxxx>]

On Wed, 2009-11-18 at 16:24 +0000, Julian Edwards wrote:
> Michael Hudson wrote:
> [snip]
> > Separately, we need to decide where a recipe lives.  The current
> > thinking is
> > "https://launchpad.net/ubuntu/karmic/+source/some-package/+recipe/recipe-name";
> > which seems OK to me (we'd have to trust a bit that this recipe would
> > build a recipe for some-package in karmic, but that doesn't seem any
> > different to say branches today).
> 
> I don't think this is good for a few reasons:
>  * The URL is too long
>  * The traversal would fail for a recipe where a source package name
> doesn't exist yet
>  * The recipe is tied to a series.  Recipes should be independent of a
> series.
>  * Why have more than one recipe for one package?
> 
> My suggestion is:
> /<distro>/+recipe/packagename

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.

> [snip]
> >    - the issues of accessing private branches from the buildslaves
> >      scares me a bit, I hope we can avoid worrying about that until some
> >      time in 2010.
> 
> Yeah, I had only considered the firewall rules from the slaves.
> 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
sounds like a recipe for trouble. In a later email, you suggested
chroots. chroots do not help. They are simple to break out of.

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.

> [snip]
> > [1] I guess the fact that these packages aren't signed will bite us in
> >    the ass somehow or other at some point, but I don't know how much it
> >    affects how this bit would work.  We don't *have* to get the source
> >    package files into Soyuz via the Librarian I guess.
> 
> Mark S has suggested that we have a single Launchpad key to sign them,
> so that if the packages are used outside of Launchpad then people know
> where they came from.

Where will they be signed? It cannot be anywhere on the slaves. Remember
that we already have lots of unsigned sources in LP (mostly syncs), and
that hasn't been much of a problem.

William.