1 |
The only attack most people really care about is a compromised rsync server. |
2 |
There is no practical way to protect against the other attacks - and at the |
3 |
end of the day, if a developer gets compromised it doesn't matter whether |
4 |
it's a gpg key or ssh key, the effect is the same. The discussion about |
5 |
which files to sign is pointless - the extra computational cost of signing |
6 |
all files in the tree is insignificant, and how are we supposed to know how |
7 |
future tools will handle things like the licenses? Just do it properly now |
8 |
and sign every file. |
9 |
|
10 |
We already trust the master cvs server admins (and they could just replace |
11 |
the whole tree anyway), so what benefit does a distributed signing system |
12 |
like gpg actually give to the developers or users? I can't see any that are |
13 |
worth the costs of key management (and there are costs, otherwise a system |
14 |
would've been put into place years ago). |
15 |
|
16 |
So my simple proposal would be to use a single key, and a post-commit cvs |
17 |
hook to sign the whole tree. It takes me 1.5 seconds with gnupg to generate |
18 |
a signature covering the whole tree on my desktop here. I don't know how |
19 |
many commits per day there are (and maybe that would be reduced with an |
20 |
atomic commit system like svn), so I don't know if this is an acceptable |
21 |
cost. I think it probably is, but if not, then signing could be done |
22 |
per-directory. |
23 |
|
24 |
The benefits of this would be that changes are minimised - developers and |
25 |
users act the same, the impact on the tree is a 191 byte signature, and yet |
26 |
it will protect against the most likely and most practical form of attack. I |
27 |
was much more pro-distributed trust system in 2003 (or whenever this was |
28 |
last discussed), but I think the right solution now is the practical, easy |
29 |
to implement one. |