On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: > The primary reason why there's only one keyring-maint is the "binary > blob" problem: [...] > [...] > This issue has been mentioned briefly in the past a few times, but to > the best of my knowledge, no one's taken up the challenge so far.
One of those mentions was in a mail to Branden as DPL in November 2005. I figure since I'm DPL now, it's fair game for me to quote the bits of that mail that don't go into any personal stuff: ] To: Branden Robinson / Debian Project Leader ] Subject: Re: keyring-maint assistance needed? ] From: James Troup ] Date: Tue, 22 Nov 2005 02:46:34 +0000 ] ] [...] ] ] I think in the long term, keyring maintenance should obviously be done ] by more than one person. ] ] But I also think the ill-effects of forcibly or hurriedly adding ] additional maintainers vastly outweigh the ill-effects of its current ] one-man state. ] ] There's also a bunch of stuff that could be done, most of which is ] being worked on, that doesn't involve adding more people or have the ] problems associated with that. ] ] The three things most need to be worked on are: ] ] (a) spam. The keyring-maint address gets something like, ] conservatively, 500 spams for every non-spam email. This is ] after 4 layers of spam filtering. Thanks to Ryan's stellar work ] on our email infrastructure there are now options available to us ] that should allow us to drop this down to 0 spams (by requiring a ] specific tag in the subject, a pseudo-header in the body or a ] specific address to be used). ] ] (b) if/when (a) gets fixed[0], I'm going to look at setting up a ] Request Tracker instance to manage the keyring. Apart from ] helping me in terms of managing (and not losing track of) ] requests, it will also allow better transparency in terms of ] people being able to see how many and what requests are ] pending[1]. The only potential problem here is finding a ] suitable machine as RT is a big scary perl web app that can ] require a lot of resources. ] ] (c) right now changes to the keyring are fundamentally unauditable ] unless they're done by a single person on a trusted machine with ] trusted scripts. There are a bunch of ways to solve this, but ] the best suggestion I've heard so far is something that breaks ] down the 17Mb binary blob of 'debian-keyring.gpg' into single key ] auditable chunks that can then be managed in a sane way. The ] scripts to do these would have to be simple first and foremost so ] they could be audited. ] ] I'm working on (a) and (b) but I'm not working on (c) because I simply ] don't have time - others are of course welcome to. I've discussed the ] idea with several people in real life, and it's come up in the thread ] on -private. I also believe that with (a) and (b) done there is no ] pressing need for (c) although it'd obviously be nice to have. ] ] [...] ] ] -- ] James ] ] [0] RT sends auto-replies so it isn't an option as long as the email ] address is getting this much spam. ] ] [1] Although given the nature of some of the emails sent to ] keyring-maint things in the RT will be private by default and only ] public when they're moved to a public queue. I summarised this portion of the mail this time last year, too, fwiw: http://lists.debian.org/debian-vote/2006/03/msg00275.html Cheers, aj
signature.asc
Description: Digital signature