Request for Adding Ubuntu Kylin Archive

[Steve Langasek]

Thanks for all the discussion.  I think we're getting close to an agreement
here; at least the broad strokes seem to be agreed already, and we just have
a few points to fine-tune, so I've begun the process with Canonical IS to
get this archive brought up so that we can have it in time for 14.04.  Do
folks think we could get a formal decision on this by, say, Thursday April
10?

On Mon, Apr 07, 2014 at 08:54:09PM -0400, Stéphane Graber wrote:

> Is it worth specifying that we expect the build time sources.list to
> match that of a regular archive upload? (all pockets enabled except for
> backports and all components enabled)

> It's also a bit of an implementation detail and probably won't matter
> too much for Kylin but if we are to reuse this process at some point
> later, it may be worth making sure things build with both -proposed and
> -updates as real uploads do.

This feels very much like an implementation detail to me, that I'd rather
not encode in the TB decision; I think the need for separate archives is
sufficiently rare that trying to generalize now is unlikely to save us time
later, and by trying to overspecify we might paint ourselves into a corner.

On Mon, Apr 07, 2014 at 09:15:22PM -0400, Stéphane Graber wrote:
> On Mon, Apr 07, 2014 at 05:40:00PM -0700, Steve Langasek wrote:

> > The Ubuntu Kylin team has captured this now in a wiki page:

> >   https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive

> > Let's please iterate there.

> So a few quick things I noticed and that the Kylin team may want to
> change before we put it to a vote (I don't think it's a good thing for
> the TB to edit a Kylin proposal directly):

Well, the Ubuntu Kylin team's initial proposal was definitively rejected by
the TB, and the proposal that's up now is just repeating things that the TB
members themselves have proposed in this thread.  So I'm sure the Ubuntu
Kylin team will forgive us for editing directly, if it lets us reach a
definitive decision faster. :)

> """It will be managed and monitored by Ubuntu Kylin Council. Up-loaders
>    should be Ubuntu members and have signed the CoC of Ubuntu. """

> Should in my opinion read:
> """It will be managed and monitored by the Ubuntu KylinCouncil.
>    Uploaders must be Ubuntu Members and have signed the Ubuntu CoC."""

> (s/should/must/ + wording)

Agreed, changed this in the wiki.

> """Packages should be built on the same infrastructure as Ubuntu, using
>    the same builder pool and build chroots."""

> Should in my opinion read:
> """Packages must be built within the same general infrastructure as
> Ubuntu (Launchpad) and using the standard Ubuntu rootfs with the same
> apt configuration."""

> (Don't require same pool but require (must) the use of Launchpad and the
> same build environment (rootfs and apt config).)

I've used the wording from my earlier email, but would be ok with changing
this in the direction of what you've written.  However, note that the apt
configuration cannot be "the same" as for the Ubuntu archive, because that
would exclude the Ubuntu Kylin ppa itself.  (This is partly why I don't
think it's worth specifying here, since it's hard to describe precisely and
there doesn't seem to be any risk that the implementation won't match what
we're expecting.)

> """The result should be signed by a GPG key managed by Canonical within
> the Canonical infrastructure."""

> Should in my opinion read:
> """The result will be signed by a GPG key managed by Canonical within
> the Canonical infrastructure. This key will be kept within Canonical and
> won't be provided to the Ubuntu Kylin team."""

> (s/should/will/ and make it very clear that the Kylin team won't have
> access to a copy of the key.)

I've made the should/will change.  I am not convinced that the second
sentence is necessary: this follows "obviously" from normal key management
practices, I don't think the TB needs to tell Canonical IS to not share
private keys with someone who doesn't need access to them.

> """That GPG key should be separate from any other key currently in use
> and should be (not a hard requirement for 14.04) signed by the archive
> master key."""
> 
> Should in my opinion read:
> """That GPG key must be separate from any other key currently in use."""

> (s/should/must/ and don't mention the trust path, we may take care of
> this separately.)

Done.

> As for the last point, the extension repository policy says that the
> various criteria are enforced by the archive administrators, which in
> this case won't be possible as this will use private PPAs.

Right.  Do you think the Extension Repository Policy should be updated to
take this into account?

> I don't think we actually want to inspect every single upload but I'd
> like the proposal to guarantee access to the packages to the Ubuntu
> Archive admin team and the Security team for audit purposes as well as
> confirm the authority of the former to request immediate removal of any
> problematic content.

> Something along the lines of:
> """The Ubuntu archive and Ubuntu Security teams act as the auditors for
> this repository and will be allowed access to the repository in all
> cases. The Ubuntu archive team may also request the immediate removal of
> any unsuitable content."""

This seems reasonable to me in principle.  Added to the wiki with minor
wording tweaks.

> This may seem redundant with what the extension repository policy says,
> however I don't believe it is once we consider that the current proposed
> implementation uses private PPAs which won't be accessible by the
> archive admins by default. This also covers the case where the kylin
> repository would become region-restricted.

> In practice what this means is that the Ubuntu archive team and Ubuntu
> security team should be added as subscribers of the private PPA so that
> they can, if needed access the content directly from Launchpad.

That sounds like a reasonable implementation; I think the auditing could
also be done via the public archive, but it would probably be more
convenient to have access via Launchpad, which we know has a speedy
connection to where the archive and security teams would be.  Anyway, these
are implementation details.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20140408/0a7d932b/attachment.pgp>