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

[Brian Harring <ferringb@gmail.com>]

On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@gmail.com> wrote:
> > One thing people need to keep in mind here is that when you sign the
> > commit, you're signing off on the history implicitly. ?Directly
> > addressing freeman's comment about "people sign the manifest but don't
> > look at what they're signing", when it comes to git signage, bluntly,
> > people doing that shouldn't have access- if they can't be arsed to
> > validate what they're signing, then trusting them w/ the tree is
> > probably questionable.
> 
> I suspect that you're missing my point.  The argument was made that as
> long as merge commits are signed you know that unsigned commits
> referenced by them are OK.  However, some of those commits might have
> been already in gentoo-x86 and I doubt that anybody is going to check
> those.

Going over the details on the offchance you're misunderstanding part 
of it:

A signed commit is a signing of the git metadata; tree hash 
(literally, the state of the tree), committer, author, message, and 
parent sha1.  Each git commit includes it's parent sha1 in it; this 
gives a locked history for a given commit sha1 (unless someone 
preimages sha1).  What matters is that the leaf node, the final point 
in the graph, is signed- that's a dev sign off on effectively that 
they created that particular locked history.  Realistically signing of 
each node is preferable, but the leaf is the minimal required.

The dev, prior to signing that, should be verifying what they're 
adding (moreso, what exists between last signed rev and theirs), they 
agree to and know of.  Specifically, they're asserting their addition.

When the dev resync's, part of the process *should* be validating that 
the new remote ToT is actually signed by a trusted key; aka, another 
dev.  For merge commits, the same applies here- due to the rather 
nice sha1 hack of git, signing the merge commit has the same angle, 
the dev signs off on the new addition effectively (for merge commits, 
moreso that the resultant integration is what they intended).

Now to pick at your statement; "the dev is signing off on commits 
already in x86"; think through this scheme; each dev signs off as they 
go on their specific changes, validating backwards is doable- meaning 
you can validate that all commits in the vcs were signed off by 
trusted folk (ie, dev's).  Your argument is either based on 
misunderstanding how this works (potentially just ignoring the pull 
validation devs have to do), or assuming that the dev is responsible 
for signing off on *everything* in the tree's proceeding history just 
because they're signing a specific history/tree sha.  As indicated 
above, they're signing off essentially on each gap between signing, 
the delta.


> If I have a perfect commit, I do a git pull and a git push and
> the result is a merge that references whatever was in gentoo-x86
> before, whether placed there by dev, or hacker, or whatever.  Unless I
> go back and review the existing gentoo-x86 history (and likely have to
> repeat the process when somebody else does a push before I do), I
> can't vouch for what was in there already - just what I'm adding.

For someone to inject something into the history requires basically a 
sha1 preimage attack, or the dev to be hit by an injection attack, 
along w/ the dev *skipping* validation of the pull to current ToT.

If we require every commit to be signed, that blocks the potential for 
a careless dev skipping the valdation to sign off on things that were 
injected.  This is a bit honerous, and is why signed pushes were the 
preference (and is a bit of an abuse what we're doing now).


> The reason I mentioned maifests is that they have the same issue.  If
> I keyword an arch on foo-1.4.5, I sign the manifest.  That doesn't
> mean that I checked every file in the package's directory tree for
> issues.  At most I checked foo-1.4.5, but I can't sign off on just
> 1.4.5 - I have to sign off on everything.  Also, when I sign off on
> 1.4.5, I'm really just signing off for the keyword change, not the
> piece of buggy code I didn't write on line 37 of the ebuild.

Manifests aren't particularly comparable, nor is it worth trying to do 
so.  Technically w/ CVS manifests you can isolate down just the delta, 
and infer that the signage was for that, but the tools don't 
particularly exist for it, nor is it worth it; cvs just isn't designed 
sanely to allow for this.

With git however, since the signing can be integrated directly into 
the revs themselves, you *are* directly signing the deltas; as said, 
w/ cvs technically you are (even if you're signing all of the 
results).

An additional note btw; to be clear, the only manifest file that 
exists in a git tree is a thin manifest holding checksums for the 
distilfes involved.

If you're thinking of rsync distributed trees (which aren't thin 
manifests), the plan was to enhance the existing rsync snapshot 
generation scripts so that they do validation of the history 
(comparing against the dev keyring), and generate signed manifests 
for rsync distribution.  Any failure in validation == no update to the 
snapshot.

If that doesn't answer your question/concerns, be more explicit 
please.
~harring