On Tue, Apr 06, 2004 at 04:08:52PM -0500, Brian W. Fitzpatrick wrote:
> I'm all for having multiple committers sign a release for the purpose of
> providing multiple trust paths to the signer's key, but I'm against the
> idea of a "shared key". I discussed this a bit with Ben Laurie, and he
> Shared keys are bad, for the obvious reason that you have to:
> a) Share it, implying some other shared form of trust in the first
> b) Revoke it when anyone leaves.
According to what I presented the only people that would need access to
the key would be the CollabNet people (presumably only the ones in
Chicago). If you guys don't trust each other then I think we have other
If you really want to be that paranoid about each other then fine, only
have one person at CollabNet be responsible (i.e. have access) to the
project key. When that person leaves then we can regen a new key. Do
people really come and go on this project that often that we'll need to
be doing this all the time?
But really using individual keys doesn't entirely solve this problem.
It just means that you have to go to the website and see who's
authorized to... Ohh yeah we can't trust the website. The fact is there
has to be some other shared form of trust here. There's no way to get
away from that.
The real question is what problem are we trying to solve here? The
problems you raise come about from not trusting the developers at
CollabNet (ironically you're one of those developers). But as things
stand no matter what we do on the signing of releases these people have
to be trusted. I'm pretty sure most (if not all) of you have access to
the repository. You also all have the ability to modify the repo. So
if you want to do something evil we're screwed anyway.
Ben Reser <firstname.lastname@example.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Apr 7 00:08:49 2004