On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman <d...@gentoo.org> wrote: > If the tree was bad before you pushed, then it's not your fault the > tree is bad. You're only responsible for the commits you bring into > the tree, so if you're merging contributor's unsigned changesets, you > merge them with a signature of your own.
Yup, but the fact that the tree is bad is still a problem, even if it isn't my fault. > If the hacker has unfettered access to the server where the repository > lives, we probably have bigger problems, as they can get whatever > rsynced to all our users. I guess we could have rsync process check > that the cset it's about to push out to mirrors is signed? So, the whole point of signing is that it lets you prove that the repository is uncompromised. If we're going to assume that the server is secure, then we don't need signatures - whatever is on the server is by definition correct. A robust security infrastructure is already spelled out in a GLEP (though that one is dated). Ideally it should be verifiable from end to end, so that when you run emerge if a package has been tampered with it will just refuse to install it. Since we don't distribute the whole git repository the git commits only get us part of the way there. However, if every step of the distribution assumes that the previous step could have been compromised that would be a good start. Again, we don't need to be there 100% to go live. However, I think that was the whole point of signing commits. If we aren't going to add any assurance at all with our signing practices, then there isn't much point in having them. Rich
