[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GR: welcome non-packaging contributors as Debian project members


Lucas Nussbaum a écrit , Le 14/09/2010 18:56:
> While I support welcoming non-packaging contributors as project members,
> I am concerned that we are creating the concept of second-class DDs (or
> at least, that it will be communicated like that).
> I see two different ways to avoid that:
> [A] Avoid giving DDs without upload rights any special name or title
> (like "Debian Contributors"). Their official title should be "Debian
> Developers", and they should only be special-cased in the documents
> where the distinction between DDs with upload rights and DDs without
> upload rights is important.
> [B] Give everybody upload rights anyway. If we trust them to influence
> the project's decisions through voting, we should probably trust them to
> do the right thing and not upload packages when they don't feel
> qualified to. After all, I am a DD, I have the technical power to make
> changes to eglibc and upload it, but I should probably not do that. Why
> am I treated differently from DCs in that regard?
> Of course, we have a problem with security, and it's probably not very
> reasonable to have 1000 DDs able to upload every package, and connect to
> every project machine. So I think that we could use this GR to ask DSA,
> DAM and keyring-maint to investigate changes to the Debian
> infrastructure that would mitigate security issues in the case of a
> compromise of a DD's credentials.  Examples, just to illustrate what I'm
> thinking about:
> - create a "limited upload rights mode", where DDs would only be allowed
>   to upload their own packages. Action from the DD, like a login on
>   db.debian.org, would be required to switch to "full upload rights
>   mode", and that mode would auto-expire after a month without any
>   upload.
> - do something similar for access to project machines.
> My own preference is [B] > [A] > [original GR proposal]. But I'd like to
> hear some other opinions before working on a draft amendment for either
> [A] or [B].

I second Lucas' proposal, with the very same preference order.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: