Removing stale PGP keys (Was: Re: cvs commit: doc/share/pgpkeys
aaron.key ...)
Doug Barton
dougb at FreeBSD.org
Mon Nov 14 00:59:58 UTC 2011
On 11/13/2011 01:15, Chris Rees wrote:
> On 13 November 2011 07:51, Xin LI <delphij at delphij.net> wrote:
>> On 11/12/11 23:30, Chris Rees wrote:
>>> crees 2011-11-13 07:30:43 UTC
>>>
>>> FreeBSD doc repository (ports committer)
>>>
>>> Modified files: share/pgpkeys pgpkeys-developers.sgml
>>> pgpkeys.ent Removed files: <lots>
>>> Log: - Remove former Developers . Thanks again for your work in
>>> the past
>> A few developers are active (sbruno, dfr, grehan at least, I haven't
>> checked everyone). Could you please send e-mails to make sure that's
>> Okay?
>
> Looks like it's a mistake-- the list I was checking against was the
> SGML source of [1]; seems some people are still missing from that list
> :/
My apologies as well. I did lightly review the patch for syntax, etc.;
however I did not myself review the list of keys removed for the purpose
of verifying that they were all in fact former committers.
> I'm reverting this commit for now, until we've sorted it.
>
>> (I personally consider having these keys beneficial unless they are
>> fully expired by the way -- consider this: one day they might send an
>> email asking to re-activate their commit bit, without the key in
>> print, we have no easy way to validate their identity unless someone
>> else have signed their keys in the past and not excluded in the handbook).
>
> I agree, however the key is still in CVS, and this is unusual enough
> that I (and it seems a few others) don't see the need for alumni's
> keys to be in the 'printed' Handbook. We need to be consistent about
> who is and who isn't in there.
There is absolutely no reason to have keys from former committers in the
Handbook. They are almost all (I'd say at least 95%) on a keyserver
somewhere, and if not, they can be dug out of CVS in the incredibly
unlikely scenario that we need to validate a signature at some point
down the road. The argument that stale keys can be used for verifying
the identity of a former committer is also almost certain to be
spurious, given that a significant percentage of the existing keys (I'd
like to say a majority, but I have no data to back that up) have long
since passed out of the control of the *existing* committers, never mind
the former ones. This isn't just pessimism/negativity on my part, it's
based on my past experience in contacting committers privately
suggesting that they update their broken keys.
> I'll open it up for discussion with core involved as well (as
> requested by another developer).
I completely fail to see how core@ should have a role here, but
hopefully they will agree with me for a change. :)
> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html
Doug
--
"We could put the whole Internet into a book."
"Too practical."
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
More information about the cvs-doc
mailing list