Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Rich Freeman]

On Fri, Jul 3, 2015 at 5:40 PM, Robin H. Johnson <robbat2@g.o> wrote:
> On Sat, Jul 04, 2015 at 12:19:41AM +0300, Andrew Savchenko wrote:
>> As I see from git docs only commits and tags may be signed. There
>> is no way to sign a push. Moreover there is no need to sign each
>> commit, see what Linux says on that:
>> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> That was Linus's 2009 opinion, and he changed his mind since then, with
> the research into further attacks on SHA1.
>

A few things.  I agree with where you're going, Robin, but I do take
issue with just one bit of your email.

First, signing commits in no way protects against attacks on SHA1.
The only thing that binds a commit record to the actual data in the
tree is an SHA1 hash.  If you are able to break SHA1 then all you need
to do is tamper with a file in the tree however you want, then add or
tamper with another file anywhere else in the tree such that the two
changes "cancel each other out" and result in the same SHA1 hash.
Then you swap out any blobs/trees you modified in the repository and
nobody is the wiser, especially with something like Gentoo where you
can stick something in a random filesdir anywhere in the tree where
nobody will notice it for a long time.  The commit record itself is
not touched, so its signature verifies just fine.

That said, I do support commit signing. It makes a lot more sense for
a project like Gentoo than a project like Linux.

With Linux, the distributed repositories everybody actually uses have
only one committer each for the most part.  The only person who
commits to mainline is Linus himself.  Then there is a release process
where all the commits for the week go out with a git tag, which is
signed.  Linus basically does the final QA on the mainline kernel
before it is released, and he assumes responsibility for every commit
that went into it.

In contrast, Gentoo has numerous committers and changes go right from
the dev's repository to every user's desktop.  When I make a commit
I'm only responsible for my own change - I don't do QA on the last 47
commits other random devs have made.  So, if the last commit doesn't
interact with mine in any way, chances are I won't do any testing of
it at all before I add my own signature - I won't even run repoman on
the entire tree.  So, a dev's commit signature is really a stamp of
quality on the diff between their commit and the last, not the tree as
a whole.  So, it really makes sense to the signing at the commit
level, and not at some higher level.  In fact, to do the signing at a
higher level really does amount to rubber-stamping changes in a way
that commit signing does not, based on how we assign responsibility.

If we were a release-based distro then tag signing would be much more important.

Finally, signing commits is really cheap, so why not just do it?

-- 
Rich