Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman <djc@g.o> 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