| 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. |
Archives