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. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
