On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@...> 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
The general principle is that if you change something in the tree, you
should be responsible for what you changed, and that makes sense.