1 |
On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote: |
2 |
> On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > One thing people need to keep in mind here is that when you sign the |
4 |
> > commit, you're signing off on the history implicitly. ?Directly |
5 |
> > addressing freeman's comment about "people sign the manifest but don't |
6 |
> > look at what they're signing", when it comes to git signage, bluntly, |
7 |
> > people doing that shouldn't have access- if they can't be arsed to |
8 |
> > validate what they're signing, then trusting them w/ the tree is |
9 |
> > probably questionable. |
10 |
> |
11 |
> I suspect that you're missing my point. The argument was made that as |
12 |
> long as merge commits are signed you know that unsigned commits |
13 |
> referenced by them are OK. However, some of those commits might have |
14 |
> been already in gentoo-x86 and I doubt that anybody is going to check |
15 |
> those. |
16 |
|
17 |
Going over the details on the offchance you're misunderstanding part |
18 |
of it: |
19 |
|
20 |
A signed commit is a signing of the git metadata; tree hash |
21 |
(literally, the state of the tree), committer, author, message, and |
22 |
parent sha1. Each git commit includes it's parent sha1 in it; this |
23 |
gives a locked history for a given commit sha1 (unless someone |
24 |
preimages sha1). What matters is that the leaf node, the final point |
25 |
in the graph, is signed- that's a dev sign off on effectively that |
26 |
they created that particular locked history. Realistically signing of |
27 |
each node is preferable, but the leaf is the minimal required. |
28 |
|
29 |
The dev, prior to signing that, should be verifying what they're |
30 |
adding (moreso, what exists between last signed rev and theirs), they |
31 |
agree to and know of. Specifically, they're asserting their addition. |
32 |
|
33 |
When the dev resync's, part of the process *should* be validating that |
34 |
the new remote ToT is actually signed by a trusted key; aka, another |
35 |
dev. For merge commits, the same applies here- due to the rather |
36 |
nice sha1 hack of git, signing the merge commit has the same angle, |
37 |
the dev signs off on the new addition effectively (for merge commits, |
38 |
moreso that the resultant integration is what they intended). |
39 |
|
40 |
Now to pick at your statement; "the dev is signing off on commits |
41 |
already in x86"; think through this scheme; each dev signs off as they |
42 |
go on their specific changes, validating backwards is doable- meaning |
43 |
you can validate that all commits in the vcs were signed off by |
44 |
trusted folk (ie, dev's). Your argument is either based on |
45 |
misunderstanding how this works (potentially just ignoring the pull |
46 |
validation devs have to do), or assuming that the dev is responsible |
47 |
for signing off on *everything* in the tree's proceeding history just |
48 |
because they're signing a specific history/tree sha. As indicated |
49 |
above, they're signing off essentially on each gap between signing, |
50 |
the delta. |
51 |
|
52 |
|
53 |
> If I have a perfect commit, I do a git pull and a git push and |
54 |
> the result is a merge that references whatever was in gentoo-x86 |
55 |
> before, whether placed there by dev, or hacker, or whatever. Unless I |
56 |
> go back and review the existing gentoo-x86 history (and likely have to |
57 |
> repeat the process when somebody else does a push before I do), I |
58 |
> can't vouch for what was in there already - just what I'm adding. |
59 |
|
60 |
For someone to inject something into the history requires basically a |
61 |
sha1 preimage attack, or the dev to be hit by an injection attack, |
62 |
along w/ the dev *skipping* validation of the pull to current ToT. |
63 |
|
64 |
If we require every commit to be signed, that blocks the potential for |
65 |
a careless dev skipping the valdation to sign off on things that were |
66 |
injected. This is a bit honerous, and is why signed pushes were the |
67 |
preference (and is a bit of an abuse what we're doing now). |
68 |
|
69 |
|
70 |
> The reason I mentioned maifests is that they have the same issue. If |
71 |
> I keyword an arch on foo-1.4.5, I sign the manifest. That doesn't |
72 |
> mean that I checked every file in the package's directory tree for |
73 |
> issues. At most I checked foo-1.4.5, but I can't sign off on just |
74 |
> 1.4.5 - I have to sign off on everything. Also, when I sign off on |
75 |
> 1.4.5, I'm really just signing off for the keyword change, not the |
76 |
> piece of buggy code I didn't write on line 37 of the ebuild. |
77 |
|
78 |
Manifests aren't particularly comparable, nor is it worth trying to do |
79 |
so. Technically w/ CVS manifests you can isolate down just the delta, |
80 |
and infer that the signage was for that, but the tools don't |
81 |
particularly exist for it, nor is it worth it; cvs just isn't designed |
82 |
sanely to allow for this. |
83 |
|
84 |
With git however, since the signing can be integrated directly into |
85 |
the revs themselves, you *are* directly signing the deltas; as said, |
86 |
w/ cvs technically you are (even if you're signing all of the |
87 |
results). |
88 |
|
89 |
An additional note btw; to be clear, the only manifest file that |
90 |
exists in a git tree is a thin manifest holding checksums for the |
91 |
distilfes involved. |
92 |
|
93 |
If you're thinking of rsync distributed trees (which aren't thin |
94 |
manifests), the plan was to enhance the existing rsync snapshot |
95 |
generation scripts so that they do validation of the history |
96 |
(comparing against the dev keyring), and generate signed manifests |
97 |
for rsync distribution. Any failure in validation == no update to the |
98 |
snapshot. |
99 |
|
100 |
If that doesn't answer your question/concerns, be more explicit |
101 |
please. |
102 |
~harring |