Re: [gentoo-scm] thin manifests

[Robin H. Johnson]

On Tue, Sep 13, 2011 at 11:19:21AM -0400, Mike Frysinger wrote:
> On Tuesday, September 13, 2011 04:00:05 Robin H. Johnson wrote:
> > 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.
>
> for the record, i dont have a problem with thin manifests by themselves
>
> > 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.
> what and how is it being signed if it isn't the Manifest today?
What: The commit or push
How: see below

> are you
> referring to signed tags ?  that's the only signing i'm aware of in git itself
> today, and signed tags would just cause a huge amount of noise ...
>
> i'm not terribly interested in possible additions to git if they aren't
> available for the foreseeable future.
There are 3 paths for signing in Git:
1. Signed tags (core, in stable)
2. Signed commits w/ signatures stored in notes tree (hooks)
3. Signed pushes (core, patches on git ML)

#1 doesn't cover what we need to.
#2 can be subverted at the client end by failing to set up the hooks,
   and it's difficult to verify on the server when receiving the packfile
   from a push (not impossible, just difficult). Also apparently
   technical issues in having multiple signatures on a single commit.
#3 Easier to verify at the receiving end, setup is really simple, just
   GPG key and 'git push -s'





>
> > > 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.
> my point here was wrt the original thin manifest proposal as Funtoo is using
> it: Manifest is not signed, and they're relying on the SHA1's that git
> provides as the foundation of their verification.  moving on to the paranoid
> point that SHA1's are brute-forcible, Funtoo's git:// sync method is
> vulnerable to a perpetual MITM attack.
>
> as for signing, if it's based on the SHA1, then it still doesn't matter.
The MITM case is a variant of my collision attack I documented earlier
in the signing discussion since the kernel.org attack. The MITM case is
actually harder, because you could subvert the entire mechanism and just
hand over an attack tree WITHOUT any verification chain at all (or
worse, hand over a custom-crafted packfile to exploit git, see the
discussion about nulls recently).

> > RESO UPSTREAM(git). It looks like Git will probably migrate to whatever
> > hash wins the SHA-3 contest.
> that's fine as long as we don't espouse SHA1's (and any system built upon it)
> as being secure.  so if we do provide anonymous git:// for syncing, we include
> the aforementioned caveats.
I'm fine with that.

> as for the devs pushing their signed SHA1's over ssh to the machine which
> produces signed Manifest2 files (as we have today), that reduces the attack
> surface to that server machine (ignoring the obvious surface of every dev
> machine where people do their commit/sign/push).  which isnt as big a deal.
1. devs push via SSH, reduced attack surface.
2. rsync users get full signed Manifest2 files, no MITM attack surface.
3. anongit users need to verify exposed blobs [1] are signed by a key in
   the Gentoo set of trusted keys (signed pushes cover commits, commits
   cover blobs). MITM potential reduced by signatures.

> i'm not sure how signing a push which includes only a single changeset is any
> better than signing a single changeset.  but i'll let them worry about it :P.
> -mike
One of the variations is that two people should be able to sign the same
push/head/commit-range, and that's apparently difficult w/ signatures
per changeset.

Footnotes:
1. "exposed blobs": At a given point in time, the set of signatures
   that for every blob in the working directory copy.


-- 
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