On Thu, Aug 25, 2011 at 12:23:40AM -0400, Mike Frysinger wrote:
> On Monday, August 22, 2011 15:28:57 Robin H. Johnson wrote:
> > Unresolved items:
> > - commit signing
> > - thin Manifests
> how exactly are these two supposed to interact ?  the previous discussion 
> seemed to miss signing.  if devs sign the thin manifests, when we go to 
> produce the full manifest for rsync, we invalidate the signature.
Thin Manifests are not going to be explicitly signed like the current
signatures.

To summarize this better:
1. Thin Manifests contain DIST lines, and _nothing_ else.
1.1. Specifically: no signatures, and esp. not any other files that
     appear in Git.
2. Commits (or pushes [1]) are signed going into Git.
2.1. Non-signed commits/pushes are REJECTED by git-receive-pack on the
     server-side.
3. Git->rsync build phase:
3.1. Verify all commit signatures.
3.2. Add metadata and other files.
3.3. Build thick Manifests.
3.4. Produce new signatures for Manifests.
3.5. MetaManifest?

> the other attack we want to prevent is MITM when people sync.  in this case, 
> someone who syncs over git:// is perpetually vulnerable with thin manifests as 
> the attacker can keep recomputing the collisions so that the modified tree 
> keeps ending up with the same digests as the public one.  and the end user 
> never notices without manually reviewing everything themselves.
I don't follow this attack. The commits are signed, and the git:// user
can verify them.

> well, it sort of does.  sha1 has been shown to be weaker than brute forcing, 
...
> talking about migrating away from it.  and now in 2012, we want to talk about 
> migrating purely to it ?
RESO UPSTREAM(git). It looks like Git will probably migrate to whatever
hash wins the SHA-3 contest.

Footnotes:
[1] Current state of commit signing, 2011/09/13 05:00 UTC
There's a variation of commit signing presently being actively discussed
on the Git mailing list. It's making a LOT more progress than previous
signing discussions. Rather than signing blobs or commits directly, it's
actually signing pushes (which include the SHA1's of commits and thus
blobs). I'm personally concerned it's going to still be vulnerable to
the collision/pre-image attacks, but it's much better than no signing
(one of the attacks suggested against my SHA1-workaround signing was to
subvert the note that my signature was being stored in).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85