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

Re: Re-thinking Debian membership

On Fri, Oct 24, 2008 at 01:49:48PM +0200, Patrick Schoenfeld wrote:
> Hi,
> On Fri, Oct 24, 2008 at 01:35:43PM +0200, cobaco wrote:
> > AIUI he's just advocating having the equivalent of a (publicly scrutinized) 
> > NMU for the keyring, that is:
> > - have trusted gatekeeper(s) who normally does all changes
> > - have all changes be public (many eyes make all bugs shallow)
> > - also have the possibility for the equivalent of an NMU, for those cases 
> > where the gatekeeper is on vacation/to busy/otherwise unavailable/goes 
> > rogue.
> and where is the difference? Still, every DD would be able to kick out
> every other DD of the keyring. Obvious the only protection against abuse
> is that it should be public. But that does not help much. If someone
> removes the key of somebody this causes damage, even if the most obvious
> damage (the removal itself) can be fixed easy and quick.

The keyring does not have to be exposed directly. It could work via a
delaying queue or stanging area. Changes commited to be applied to the
keyring could be made publicly available for peer-review. This would
make it possible that any change could be veto'ed by any other project
member during the delay period.

If anyone's key is about to be removed from the keyring that person could
recieve a message informing about the scheduled removal and could object
him/herself. If anyone has to be expelled the DPL/TC/Keyring maintainers
could apply the change directly.

The same mechanism could be the place for more automatic sanity checks,
such as, checking whether a key that is about to be added is properly
signed by a certain required number of other project members, ie.
something like a "keyring-lintian".

In general and if trust is the default assumption within the project
such procedure would remove a potential human bottleneck and only
requires manual intervention if the trust-assumption is violated or
something happens that is not (yet) covered by a "lintian" check.

Of course such a system could be abused, but the staging of all changes
would make sure that the environment does not suffer from unexpected,
harmful changes.


GPG key:  1024D/3144BE0F Michael Hanke
ICQ: 48230050

Reply to: