Giving upload rights to non-Ubuntu members

Scott Kitterman ubuntu at kitterman.com
Sat Jul 27 18:45:33 UTC 2013


Mark Shuttleworth <mark at ubuntu.com> wrote:
>On 25/07/13 02:42, Scott Kitterman wrote:
>> e.g. instead of PPU for 5 related packages, here's a small packageset
>> that we'll let you upload to. For these kinds of cases, PPU for X
>> packages or create a packageset is only an adminstrative difference. 
>
>Agreed, it's more efficient to express collections as a packageset, and
>to be encouraged.
>
>> As a practical matter, I expect this new option to primarily apply to
>> Debian developers that are someone interested in their packages in
>> Ubuntu, but not making a major commitment to it. If their keys get
>> compromised we're in trouble whether they have upload rights to
>Ubuntu
>> or not. Scott K 
>
>That's only true if we track their debian permissions. If they were to
>become inactive in Debian, but we left their keys active, we'd be
>vulnerable in the way I described.
>
>In general there are means and mechanisms to apply a 'steady wind' that
>blows things in the right direction. For example, with Ubuntu
>membership, you need to ask to renew it or it lapses. I think we should
>be mindful that many granular permissions that are granted and then not
>watched is a recipe for a dark corner filling with dust bunnies that
>might catch fire later.
>
>In short, I'm absolutely +1 on upload permissions being decoupled from
>membership, and actively encouraged as a way to bring folks into
>development who are skilled and interested and focused on particular
>sets of packages. But I think we should be WISE about that and aim to
>have a self-gardening system throughout. Otherwise, in 10 years time
>there will be a very long list of permissions out there, not all of
>which are relevant, and nobody will have time to garden it until we
>have
>a problem.

Although we didn't document it in the proposal, the new upload permissions would have an expiration date and require self renewal, like other development permissions.

Scott K





More information about the technical-board mailing list