9

For a non-public repository, are there any potential security concerns in sharing git commit hashes? For example, when I post a git-related stackoverflow question that involves git commits from private repos, I will change the hashes slightly out of paranoia.

Or perhaps a website will serve a git commit hash in a header to show what version of the code the site is running to internal developers.

Continuing the thought, are there any concerns about an attacker getting access to sequential sha1 hashes?

Andy Ray
  • 1,098
  • 1
  • 8
  • 12

2 Answers2

15

As explained there, the SHA-1 hashes are identifiers for the stored objects, including commits -- they are computed deterministically from the object contents. There is no secret in there. Though SHA-1 is nominally one-way, this would theoretically allow an attacker, who wants to guess the contents of an object, to verify whether his guess is correct or not. This would entail guessing exactly, down to the last bit, including time stamps and other similar things.

If your object contains some secret data which can be brute-forced (e.g. a password, subject to dictionary attacks), then an attacker might use the SHA-1 hash as a test. This seems hard because of the condition on guessing everything else properly, but the possibility is there. Therefore, if your commit contains such secret data, you are right to change the hash value -- but in that case, don't change it slightly, because a quasi-match is as good as an exact match on hash values, for the attacker. Change the hash values completely: replace each one of them with a sequence of 40 random hexadecimal characters.

Note that knowing the hash values does not grant any other extra power to the attacker; in particular, they do not give him access to the repository.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
0

For a non-public repository, are there any potential security concerns in sharing git commit hashes?

Most definitely not. There is absolutely no way you can correlate the SHA 1 hash of a git commit to the actual contents of the commit.

Continuing the thought, are there any concerns about an attacker getting access to sequential sha1 hashes?

What exactly do you mean by sequential SHA 1 hashes?

  • let's say I commit, and an attacker knows the exact contents of that commit, and has the sha1. If I commit a password *only* in the next commit, and the attacker gets the sha1 of the next (sequental) commit, how trivial would it be to expose the password? – Andy Ray Aug 27 '13 at 05:52
  • @DelvarWorld I do suggest you read up on the properties of a strong hash. What you are suggesting is completely impossible. –  Aug 27 '13 at 05:56