{"thread":{"id":"32144","subject":"verifying git file contents without checking out history?","startedAt":"2012-11-19T01:50:35Z","lastAt":"2012-11-19T05:32:50Z","messageCount":3,"participants":["Marc Weber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203498","messageId":"1353287836-sup-270@nixos","threadId":"32144","inReplyTo":null,"subject":"verifying git file contents without checking out history?","fromName":"Marc Weber","fromEmail":"marco-oweber@gmx.de","sentAt":"2012-11-19T01:50:35Z","receivedAt":"2012-11-19T01:50:35Z","isPatch":false,"sender":{"key":"marco-oweber@gmx.de","avatar":null},"body":"git clone --depth=20 $url; git checkout $hash\n\nHow to verify that I have the contents I think I have - given that I\ntrust my local git executable?\n\nWould it be enough to also store the git log --pretty=format:%T $hash\nvalue and check that only? %T is the root tree hash.\n\nDoes git checkout verify the file tree checksum when receiving all blob\nobjects from a server?\nThen verifying that %T didn't change should be enough to enable me\nfetching sources and trust them without running git fsck which would\nfetch all history.\n\nMarc Weber\n"},{"id":"203500","messageId":"7vtxsmxkcp.fsf@alter.siamese.dyndns.org","threadId":"32144","inReplyTo":"1353287836-sup-270@nixos","subject":"Re: verifying git file contents without checking out history?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-19T04:55:18Z","receivedAt":"2012-11-19T04:55:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Weber <marco-oweber@gmx.de> writes:\n\n> git clone --depth=20 $url; git checkout $hash\n>\n> How to verify that I have the contents I think I have - given that I\n> trust my local git executable?\n\nDefine what you mean by \"contents\".  Do you care only about the tree\nstate recorded in that $hash, and you also trust that $hash is the\ncorrect one?\n\n  $ git cat-object commit $hash | git hash-object --stdin -t commit\n\nwould be a way to verify that you do have the commit object\neverybody else calls $hash, and you can verify the objects contained\nwithin the commit whose name is $hash (i.e. its tree and its\nparents) in a similar way.  Use \"git ls-tree $tree\" to find out the\nobjects your top-level tree recorded in the commit $hash, and you\ncan verify the contents recorded in the tree object recursively.\n"},{"id":"203501","messageId":"1353303050-sup-4193@nixos","threadId":"32144","inReplyTo":"7vtxsmxkcp.fsf@alter.siamese.dyndns.org","subject":"Re: verifying git file contents without checking out history?","fromName":"Marc Weber","fromEmail":"marco-oweber@gmx.de","sentAt":"2012-11-19T05:32:50Z","receivedAt":"2012-11-19T05:32:50Z","isPatch":false,"sender":{"key":"marco-oweber@gmx.de","avatar":null},"body":"\nExcerpts from Junio C Hamano's message of Mon Nov 19 05:55:18 +0100 2012:\n> Define what you mean by \"contents\".\ncontents = the files git archive HEAD would put into an archive, those\ndetermining a build result.\n\nHow could the repo be compromised:\n1) An attacker triest to find a hash collision in the HEAD tree.\n  However finding a hash collision which also is a useful attack should\n  be very hard.\n\n2) The attacker modifies a file the way he likes (thus the attack is\n  easy), then he tries to modify the history in a way causing the same \n  commit hash.\n  Probably this is very hard, too.\n\nDoes this make sense? I feared that having a HEAD^ you can manipulate to\nchange the hash of HEAD makes it easier to cause a collision without the\nuser noticing. \nHowever adding additional useless files to HEAD could be used to cause a\nimaginary hash collision, too. Thus having a second hash would not be of\nany benefit. Thus referring to commit by hash (using all hash digits) is\nbest you can do. I finally got it.\n\nThanks\nMarc Weber\n"}]}