1

I would like to know if it secure to use a git sha for pointing to a particular version of a dependency. I know that is not a good practice, but sometimes it is needed.

I already read that, normally, it is not possible to choose the commit Id because it is calculated automatically using a lot of stuff. But nobody mentions that you can rebuild git locally for overriding this algorithm, and let's to generate duplicate sha.

And i didn't read that gitserver checks it in order to make sure the gitclient is not "broken" is that way.

So, supposing the above situation is possible (please confirm it or not), is the sha git considered sicured?

allevo
  • 844
  • 1
  • 9
  • 20
  • 1
    maybe I misunderstand the question but what's the problem using the default commit hash system? – Irelia Apr 04 '22 at 23:09
  • No one if the hash system is my own. The problem happen if I need to relay on a dependency developed externally: if I point to that dependency using a git sha, what happen if the external evil developer overwrite the content of the commit leaving the sha unaltered? – allevo Apr 04 '22 at 23:16
  • So your issue isn't necessarily commit hashes but rather the fear of someone forcing a commit leaving a hash unchanged? That's a possibility for any repository but you use git trusting that people will adhere to the general rules. If you're really concerned though couldn't you clone/fork disconnect from the remote repo? – Irelia Apr 04 '22 at 23:39
  • See also [How does the newly found SHA-1 collision affect Git?](https://stackoverflow.com/q/42433126/1256452) – torek Apr 05 '22 at 00:11

1 Answers1

5

The kind of trick you are talking about is called a preimage attack. Current techniques for generating deliberate SHA-1 collisions require that the bogus-duplicate's content contain a large "binary area"—basically a contiguous blob of bytes—where attacker can manipulate those bytes. PDF images are good candidates here because PDFs may contain such blocks.

Git commit and tag objects, however, do not contain such blocks. They do have an area in which one could drop a block like this, but this area shows us as the log message or tag message when you examine the commit (with git log or git show) or the tag (with git show). It would be hard for a human to miss the fact that at the point the particular commit or tag was "blessed" as "okay to use", the message was something like:

Release version x.y

and now it's:

Release version x.y
filler filler filler ... filler
<random bytes to produce desired hash>
<this section goes on and on for many pages>
footer footer footer ... footer

An automated software system that doesn't bother looking at the commit message or tag message could be fooled, but it would be simple enough to add an entropy detector that notices that what's in the message here no longer matches the kind of data humans generate (which has relatively low entropy; see this blog entry on Shannon entropy and this IBM security document). That's a dead giveaway, and that computation can be automated.

(The message size will also have jumped from "tiny" to "relatively huge", which can be used as well, perhaps independently.)

Still, if you like, you can experiment with the new SHA-256 variant of Git. (You cannot mix variants though: you must either use SHA-1 only, or SHA-256 only. At least, that's the case today.)

torek
  • 448,244
  • 59
  • 642
  • 775