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
Attachment:
signature.asc
Description: Digital signature