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