Integrity protection of fetches (Re: The move to git!)

Adam Williamson awilliam at redhat.com
Wed Aug 4 16:42:01 UTC 2010


On Wed, 2010-08-04 at 01:33 -0700, Matt McCutchen wrote:
> On Tue, 2010-08-03 at 22:09 +0000, Ben Boeckel wrote:
> > Matt McCutchen <matt at mattmccutchen.net> wrote:
> > > No.  If the attacker MITMs the entire connection, they can lie about the
> > > values of the remote refs too, so there is no need to find a hash
> > > collision.
> > 
> > And how would you then be allowed to push? The git server would see that
> > your history doesn't match the history it has and will refuse the
> > commits.
> 
> When the maintainer fetches, the attacker adds malicious commits on top
> of the real remote ref value, and then the maintainer pushes those
> commits as if he committed them himself.  But IMNSHO, malicious
> alteration of a fetch is something maintainers shouldn't have to deal
> with, regardless of what the consequences might or might not be.
> 
> (I should have changed the subject two round trips ago.  Oh well...)

I suspect it might short-circuit the 'ahhh, but what about...' 'oooh,
but then I can...' nature of the conversation if you just put together a
proof-of-concept attack and document it somewhere. I suspect the git
maintainers might be interested at that point as well. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the devel mailing list