0

Let's say the user downloads the git repository revision with a particular hash. For example with this command: git clone --depth 1 --branch mybranch https://mygitserver.com/x.git && cd x && git checkout {hash}.

Let's assume the git server isn't trustworthy, It might be compromised, hacked in some way. It might be attempting to alter the content in some malicious way.

Does the client actually recompute hashes of the whole content and fail in case of a wrong hash?

If the clone is shallow and only has depth=1 this means that the history is lost. Does each commit hash actually include the whole source hash, or only the delta hash? It appears that the latter is only reasonable, otherwise in case of deep histories it will have to recompute hash over and over again.

My suspicion is that it just takes the previous hash, adds the latest commit delta and metadata to it, and gets that latest hash. What about the parts of the code unchanged by the latest commit? Do they factor into the latest hash in question computed when the client downloads them this way?

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
Flying Jay
  • 179
  • 1
  • 2
  • 10
  • If somebody compromised the server and did anything bad to your commit history and replaced the complete git history you will never find out unless you pull from a other source and compare each other. You get a history and you trust this history, if it got replaced completely you can't figure it out. – ckruczek Jun 14 '17 at 04:44
  • A minor note: "hashtag" is the thing on Twitter, "hash" is what Git does. – Dietrich Epp Jun 14 '17 at 04:53

1 Answers1

0

To my knowledge, Git clone and fetch do not validate object integrity (hash mismatch). This is according to Which git commands perform integrity checks?, but that information may be out of date.

If you want to check that the SHA-1 hash of your commit is correct,

git fsck

This validates history, but obviously this won't validate objects you don't have, like in shallow repositories.

Note that SHA-1 is vulnerable to collision attacks, so you can't "guarantee" object integrity with SHA-1 in any reasonable sense of the word "guarantee".

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • _Note that SHA-1 is vulnerable to collision attacks, so you can't "guarantee" object integrity with SHA-1 in any reasonable sense of the word "guarantee"._ while this is literally true, since 2.13 there is an ad-hoc analysis which should recognize the known ways to make a collision. – max630 Jun 14 '17 at 11:58
  • There are configuration variables `fetch.fsckObjects`, `receive.fsckObjects` and `transfer.fsckObjects` to run it automatically at corresponding operation – max630 Jun 14 '17 at 12:00