On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferri...@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. 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. 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. Of course when merging a pile of commits into the tree you should check all of them to make sure they're fine (or rather that the end result of them is fine - no absolute need to squash together bug introductions and fixes even if that is nicer). However, I'm not sure I'd extend that to checking commits ALREADY in gentoo-x86 made by some other dev. The general principle is that if you change something in the tree, you should be responsible for what you changed, and that makes sense. Rich
