1 |
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> One thing people need to keep in mind here is that when you sign the |
3 |
> commit, you're signing off on the history implicitly. Directly |
4 |
> addressing freeman's comment about "people sign the manifest but don't |
5 |
> look at what they're signing", when it comes to git signage, bluntly, |
6 |
> people doing that shouldn't have access- if they can't be arsed to |
7 |
> validate what they're signing, then trusting them w/ the tree is |
8 |
> probably questionable. |
9 |
|
10 |
I suspect that you're missing my point. The argument was made that as |
11 |
long as merge commits are signed you know that unsigned commits |
12 |
referenced by them are OK. However, some of those commits might have |
13 |
been already in gentoo-x86 and I doubt that anybody is going to check |
14 |
those. If I have a perfect commit, I do a git pull and a git push and |
15 |
the result is a merge that references whatever was in gentoo-x86 |
16 |
before, whether placed there by dev, or hacker, or whatever. Unless I |
17 |
go back and review the existing gentoo-x86 history (and likely have to |
18 |
repeat the process when somebody else does a push before I do), I |
19 |
can't vouch for what was in there already - just what I'm adding. |
20 |
|
21 |
The reason I mentioned maifests is that they have the same issue. If |
22 |
I keyword an arch on foo-1.4.5, I sign the manifest. That doesn't |
23 |
mean that I checked every file in the package's directory tree for |
24 |
issues. At most I checked foo-1.4.5, but I can't sign off on just |
25 |
1.4.5 - I have to sign off on everything. Also, when I sign off on |
26 |
1.4.5, I'm really just signing off for the keyword change, not the |
27 |
piece of buggy code I didn't write on line 37 of the ebuild. |
28 |
|
29 |
Of course when merging a pile of commits into the tree you should |
30 |
check all of them to make sure they're fine (or rather that the end |
31 |
result of them is fine - no absolute need to squash together bug |
32 |
introductions and fixes even if that is nicer). However, I'm not sure |
33 |
I'd extend that to checking commits ALREADY in gentoo-x86 made by some |
34 |
other dev. |
35 |
|
36 |
The general principle is that if you change something in the tree, you |
37 |
should be responsible for what you changed, and that makes sense. |
38 |
|
39 |
Rich |