Request for Adding Ubuntu Kylin Archive

Steve Langasek steve.langasek at ubuntu.com
Fri Apr 4 01:39:36 UTC 2014


Hi Jack,

On Tue, Apr 01, 2014 at 11:42:34PM +0800, jackyu at ubuntukylin.com wrote:
> Hi Technical Board,

> I'm writing to request to add an archive for Ubuntu Kylin flavor. This
> archive mainly includes Chinese commercial packages co-developed by Ubuntu
> Kylin team and commercial companies.  We also developed a software center
> client that supports both Ubuntu archive and Ubuntu Kylin archive.

> This request have already been supported by Jason, Leonard, Anthony, etc.
> from Canonical team.  We know that in the rules of Ubuntu, flavors are not
> allowed to add archives.  However, Ubuntu Kylin is a little special since
> it mainly focuses on Chinese users.  Our partners (Such as Sogou, King
> soft) want to locate their apps in China.

> Do you have any comments on this? Thanks in advance.

Thank you for raising this issue before the Technical Board.  I understand
that you've already gone through the process of discussing this with
Canonical's business team, so having to discuss it all again with the TB is
probably very frustrating.  However, the TB has a mandate to provide
independent oversight for the technical decisions made around Ubuntu and its
flavors, to ensure transparency and accountability to Ubuntu's founding
principles.  So I ask that you bear with us as we get up to speed on
Ubuntu Kylin's needs.

We of course don't want to block any legitimate activities by any of the
Ubuntu flavors - our purpose is to facilitate the Ubuntu community in doing
great things, not to be a roadblock to progress! - but our default position
will be one of natural conservatism: our goal is to make Ubuntu sustainable
and coherent over the long term, so when something like a new archive is
proposed, we will want to understand why it doesn't fit among the (already
quite complex) set of existing archives.

For the reference of everyone here, there is an existing, Tech
Board-approved policy regarding the addition of extension repositories:

  https://wiki.ubuntu.com/ExtensionRepositoryPolicy

I think the conversation here should be focused around how the proposed new
archive does or doesn't fit this policy, and if there are ways in which the
existing policy falls short.

For instance, point 1.8 of this policy talks specifically about Canonical. 
It's worth understanding the reasons why this is, and how these reasons
apply to the question of an archive with a separate root of trust (i.e.,
NUDT).

As the original seed of the Ubuntu community, Canonical is in a unique
position of absolute trust within that community.  Canonical manages the
infrastructure on which the Ubuntu archive runs, sets the security policies
governing access to the signing keys in use, and protects the integrity of
the overall system.  The Ubuntu community, in turn, implicitly trusts
Canonical to carry out this function; this is not just because several
members of the TB are employed by Canonical, but because there must be
*some* root of trust, which for Ubuntu is Canonical.

However, it seems that the proposal being discussed here is to add a second
root of trust for the Ubuntu community.  One root of trust is necessary; two
roots of trust, however trustworthy, are a weakness, and one we should try
to avoid.

My understanding is that - answering Martin's question - the software you're
proposing to put in this archive is commercial software that Canonical does
not have the rights to distribute.  Only NUDT, Ubuntu Kylin's commercial
backer in China, has these distribution rights.  It makes sense that Chinese
software companies may prefer to do business with other companies in China,
rather than foreign companies like Canonical; and just as we have
archive.canonical.com (the Canonical partner archive) to make sure that free
redistribution from our mirrors is not an obstacle to our users having
access to a piece of software, if there is software that's interesting to
our users which *Canonical* cannot distribute, but one of our partners in
the Ubuntu community can, we should consider how we can enable this software
to be made available within the Ubuntu framework instead of outside of it.

Some questions that I think will help clarify:

 - It's understood that the package archive server will be located in China
   and that only NUDT will have the rights to distribute the packages.  But,
   is there a license reason that we could not do the package *builds* on
   the existing Launchpad infrastructure, in a private ppa or other private
   archive?  This would make it possible to do the package builds using the
   existing trusted infrastructure, and to do all package signing using the
   existing archive keys, while publishing the packages for distribution
   only under control of the Ubuntu Kylin team.  Would this satisfy the
   requirements from the Kylin side?

 - If you must run your own signing infrastructure, who will have access to
   the archive servers (both remote access and local access)?  Who will have
   access to the master signing key?  What are the archive key rotation
   policies for this archive?

 - What are the criteria that the Ubuntu Kylin Council would use to decide
   what packages will be included in this new archive?  Will this archive
   comply with the existing https://wiki.ubuntu.com/ExtensionRepositoryPolicy
   requirements?

 - Will users of Ubuntu Kylin (and Ubuntu) outside of China be able to
   download these packages, or will access be geographically limited?

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/20140403/23814a4f/attachment-0001.pgp>


More information about the technical-board mailing list