1 |
On Monday, August 22, 2011 15:28:57 Robin H. Johnson wrote: |
2 |
> Unresolved items: |
3 |
> - commit signing |
4 |
> - thin Manifests |
5 |
|
6 |
how exactly are these two supposed to interact ? the previous discussion |
7 |
seemed to miss signing. if devs sign the thin manifests, when we go to |
8 |
produce the full manifest for rsync, we invalidate the signature. |
9 |
|
10 |
also, a previous assertion was made which i think is incorrect: |
11 |
Due to the distributed nature of git, to do mischief, you need to |
12 |
change every clone in the world to be successful |
13 |
each new sha1 comes from the previous state + new data. so injecting code |
14 |
into the tip and finding a collision is not impossible and does not require |
15 |
modification of anything before it. it would only be detected automatically |
16 |
by people who have the original commit, make new commits on top of that, and |
17 |
then attempt to push back again to the modified tree. i.e. the attack is made |
18 |
against the source Gentoo repo sitting on our machines. |
19 |
|
20 |
the other attack we want to prevent is MITM when people sync. in this case, |
21 |
someone who syncs over git:// is perpetually vulnerable with thin manifests as |
22 |
the attacker can keep recomputing the collisions so that the modified tree |
23 |
keeps ending up with the same digests as the public one. and the end user |
24 |
never notices without manually reviewing everything themselves. |
25 |
|
26 |
further, it was stated: |
27 |
This has nothing to do with strength of the hash used by git |
28 |
well, it sort of does. sha1 has been shown to be weaker than brute forcing, |
29 |
and while right now it might not be computationally feasible to inject useful |
30 |
code in realtime, that is not something we should be betting on. attacks only |
31 |
get better over time ... even in 2004 security conscious people started |
32 |
talking about migrating away from it. and now in 2012, we want to talk about |
33 |
migrating purely to it ? |
34 |
-mike |