1 |
On Tue, Sep 13, 2011 at 11:19:21AM -0400, Mike Frysinger wrote: |
2 |
> On Tuesday, September 13, 2011 04:00:05 Robin H. Johnson wrote: |
3 |
> > On Thu, Aug 25, 2011 at 12:23:40AM -0400, Mike Frysinger wrote: |
4 |
> > > On Monday, August 22, 2011 15:28:57 Robin H. Johnson wrote: |
5 |
> > > > Unresolved items: |
6 |
> > > > - commit signing |
7 |
> > > > - thin Manifests |
8 |
> > > |
9 |
> > > how exactly are these two supposed to interact ? the previous discussion |
10 |
> > > seemed to miss signing. if devs sign the thin manifests, when we go to |
11 |
> > > produce the full manifest for rsync, we invalidate the signature. |
12 |
> > |
13 |
> > Thin Manifests are not going to be explicitly signed like the current |
14 |
> > signatures. |
15 |
> > |
16 |
> > To summarize this better: |
17 |
> > 1. Thin Manifests contain DIST lines, and _nothing_ else. |
18 |
> > 1.1. Specifically: no signatures, and esp. not any other files that |
19 |
> > appear in Git. |
20 |
> |
21 |
> for the record, i dont have a problem with thin manifests by themselves |
22 |
> |
23 |
> > 2. Commits (or pushes [1]) are signed going into Git. |
24 |
> > 2.1. Non-signed commits/pushes are REJECTED by git-receive-pack on the |
25 |
> > server-side. |
26 |
> what and how is it being signed if it isn't the Manifest today? |
27 |
What: The commit or push |
28 |
How: see below |
29 |
|
30 |
> are you |
31 |
> referring to signed tags ? that's the only signing i'm aware of in git itself |
32 |
> today, and signed tags would just cause a huge amount of noise ... |
33 |
> |
34 |
> i'm not terribly interested in possible additions to git if they aren't |
35 |
> available for the foreseeable future. |
36 |
There are 3 paths for signing in Git: |
37 |
1. Signed tags (core, in stable) |
38 |
2. Signed commits w/ signatures stored in notes tree (hooks) |
39 |
3. Signed pushes (core, patches on git ML) |
40 |
|
41 |
#1 doesn't cover what we need to. |
42 |
#2 can be subverted at the client end by failing to set up the hooks, |
43 |
and it's difficult to verify on the server when receiving the packfile |
44 |
from a push (not impossible, just difficult). Also apparently |
45 |
technical issues in having multiple signatures on a single commit. |
46 |
#3 Easier to verify at the receiving end, setup is really simple, just |
47 |
GPG key and 'git push -s' |
48 |
|
49 |
|
50 |
|
51 |
|
52 |
|
53 |
> |
54 |
> > > the other attack we want to prevent is MITM when people sync. in this |
55 |
> > > case, someone who syncs over git:// is perpetually vulnerable with thin |
56 |
> > > manifests as the attacker can keep recomputing the collisions so that |
57 |
> > > the modified tree keeps ending up with the same digests as the public |
58 |
> > > one. and the end user never notices without manually reviewing |
59 |
> > > everything themselves. |
60 |
> > |
61 |
> > I don't follow this attack. The commits are signed, and the git:// user |
62 |
> > can verify them. |
63 |
> my point here was wrt the original thin manifest proposal as Funtoo is using |
64 |
> it: Manifest is not signed, and they're relying on the SHA1's that git |
65 |
> provides as the foundation of their verification. moving on to the paranoid |
66 |
> point that SHA1's are brute-forcible, Funtoo's git:// sync method is |
67 |
> vulnerable to a perpetual MITM attack. |
68 |
> |
69 |
> as for signing, if it's based on the SHA1, then it still doesn't matter. |
70 |
The MITM case is a variant of my collision attack I documented earlier |
71 |
in the signing discussion since the kernel.org attack. The MITM case is |
72 |
actually harder, because you could subvert the entire mechanism and just |
73 |
hand over an attack tree WITHOUT any verification chain at all (or |
74 |
worse, hand over a custom-crafted packfile to exploit git, see the |
75 |
discussion about nulls recently). |
76 |
|
77 |
> > RESO UPSTREAM(git). It looks like Git will probably migrate to whatever |
78 |
> > hash wins the SHA-3 contest. |
79 |
> that's fine as long as we don't espouse SHA1's (and any system built upon it) |
80 |
> as being secure. so if we do provide anonymous git:// for syncing, we include |
81 |
> the aforementioned caveats. |
82 |
I'm fine with that. |
83 |
|
84 |
> as for the devs pushing their signed SHA1's over ssh to the machine which |
85 |
> produces signed Manifest2 files (as we have today), that reduces the attack |
86 |
> surface to that server machine (ignoring the obvious surface of every dev |
87 |
> machine where people do their commit/sign/push). which isnt as big a deal. |
88 |
1. devs push via SSH, reduced attack surface. |
89 |
2. rsync users get full signed Manifest2 files, no MITM attack surface. |
90 |
3. anongit users need to verify exposed blobs [1] are signed by a key in |
91 |
the Gentoo set of trusted keys (signed pushes cover commits, commits |
92 |
cover blobs). MITM potential reduced by signatures. |
93 |
|
94 |
> i'm not sure how signing a push which includes only a single changeset is any |
95 |
> better than signing a single changeset. but i'll let them worry about it :P. |
96 |
> -mike |
97 |
One of the variations is that two people should be able to sign the same |
98 |
push/head/commit-range, and that's apparently difficult w/ signatures |
99 |
per changeset. |
100 |
|
101 |
Footnotes: |
102 |
1. "exposed blobs": At a given point in time, the set of signatures |
103 |
that for every blob in the working directory copy. |
104 |
|
105 |
|
106 |
-- |
107 |
Robin Hugh Johnson |
108 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
109 |
E-Mail : robbat2@g.o |
110 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |