On 14-04-07 09:15 PM, Stéphane Graber wrote: > On Mon, Apr 07, 2014 at 05:40:00PM -0700, Steve Langasek wrote: >> On Fri, Apr 04, 2014 at 05:34:38PM -0400, Stéphane Graber wrote: >>>>> I think building the software in a private PPA, and then mirroring the >>>>> signed PPA onto NUDT's infrastructure would be a reasonable way of >>>>> achieving all the requirements. >> >>>>> Would that be an acceptable solution? >> >>>> It sounds like it meets Ubuntu Kylin's needs, but I would be wary of us >>>> trying to dictate the technical details at this level. We might find that >>>> this is the best technical implementation, or we might find that something >>>> closer to partner, where packages are uploaded to a central archive queue >>>> and managed using the Ubuntu archive tooling, makes more sense. >> >>> I think we can at least set the following high level requirements: >> >> 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): > > """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)
+1 > > > > """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).) +1 > > > > """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.) +1 > > > > """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.) +1 > > 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. > > 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 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. > +1 Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
