Scripsit Anand Kumria <[EMAIL PROTECTED]> > On Mon, Nov 21, 2005 at 02:18:02AM +0100, Henning Makholm wrote:
>> If somebody designs and implements (after a suitable architectural >> review) some software to support distributed keyring maintenance in a >> secure, auditable way, it is likely that calls for adding more people >> to the task would be considered more seriously. > This is an interesting technical position but one that I think is > incorrect. On the contrary, you seem to be focusing on the _easy_ part of the problem (which rules to use when taking the decision). The _hard_ part is to _implement_ the decision in a secure way once the rules determine that the keyring should be updated. > As I have indicated above, I do not believe the role of keyring-maint is > to make *any* decision but to act upon the instructions of other parts > of Debian (QA, DAM, tech-ctte, DPL(s), DDs via GR). The core of the problem is not decision-making. > Ideally the role of keyring-maint can be useful performed by a script Strong disagreement. A function as sensitive and fundamental as maintaining the authoritative _master copy_ of the Debian keyring should not be left entirely to an unattended script. There must be real people in the loop who can monitor the changes for unusual patterns. > but since the set of entities who could instruct the keyring-maint is > large it would probably make sense to have a number of humans fronting > that script. Producing some software that *can* be fronted for by more than one human without introducing unacceptable security risks is the problem I'm pointing to. -- Henning Makholm "*Tak* for de ord. *Nu* vinker nobelprisen forude." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
