On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote: > 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 difference is how you handle any problems. You can't avoid it, but you can reduce the impact.
> 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. In theory yes. Practically you have to find a non-intrusive way so signatures are per file. There are potential problems with "special" files like package.mask that will be modified often by different people ... signing that is a bit silly > 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). No central authority --> no single point of failure Give me a central server and I will focus on hacking that ... hacking 50 developers is much harder ;-) > 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. I don't see what that gains you ... what exactly does this signature express? and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1 minute even on a fast system > 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. So ... DoS scenario I just add one byte to the tree and the signature fails ... what then? > 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. I think I'd prefer a hybrid. One possibillity would be: - every dev signs as it is done now - post commit an automated signature from a master key is added so the normal user can check the master signature, and the paranoid people can use the per-dev keys. Where I fully agree is "practical" and "low impact" - it should be easy to use so that everyone can use it without lots of configuring. This of course limits the complexity that we can allow. wkr, Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
