On Tue, Apr 06, 2004 at 06:04:54PM -0500, Travis P wrote:
> The shared project key has exactly the same problem that you attribute
> to the individual key case. How do you know which "project key" is
> trustable?
I would argue that anytime we're going to plan to change the project key
we'd make a big effort to let people know. An email to the announcement
list well in advance saying that the key was changing. /topic change on
the IRC channel. Note on the website. etc...
Now the difference here is that there's little reason to change the
project key on a regular basis. However, individual signing alone means
different people will end up signing a release. We may not really know
who's going to sign a release until we sit down to do it.
An attacker trying to trick people into believe a new key was a project
key would have to put out a new key and a new release in near
succession. The solution is to simply say we'll never do that. That
we'll always make an effort to provide suitable notice about a key
change. If we're going to have to change a key right in the middle of a
release the best option is to simply delay the release.
If an attacker tries to publish a new key with the waiting time, it's
likely to get noticed by someone related to the project that knows
better.
> Either the website or via some chain of trust with which
> you satisfy yourself via some individual(s) in common with the project
> key. If it is useful, it is only because it is "blessed" by a group
> that could sign the package each themselves and probably will anyway.
> The shared key seems an unnecessary complication.
Yeah it's complicated to deal with. But we can either push the
complication off onto our users or we can deal with it ourselves. This
is another case of optimizing for users rather than developers. The
project key is for users. Developers or people who follow the project
closely are much more likely and able to use individual keys.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 01:24:58 2004