Re: [gentoo-scm] thin manifests

[Mike Frysinger]

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

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

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

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.

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] 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).

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