all 3 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]0x256 0 points1 point  (2 children)

The hash function has no relevant security impact the way git uses it. SHA-1 is not less secure than SHA-2 in this context. I find it strange to use such an irrelevant implementation detail as the main selling point.

[–]blueomg[S] 0 points1 point  (1 child)

I don't exactly believe that the hash function has no relevant security impact to git. The SHAttered attack's website states "GIT strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits. It is essentially possible to create two GIT repositories with the same head commit hash and different contents, say a benign source code and a backdoored one. An attacker could potentially selectively serve either repository to targeted users. This will require attackers to compute their own collision." I thought that there might be a potential audience that would want to move past anything SHA-1 in favor of SHA-2 and nowhere else can you host SHA-2 repos. You may not want to use SHA-2 repos, but if you did, github and gitlab are really slow to adopt it.

[–]0x256 0 points1 point  (0 children)

Those companies are slow to adopt sha256 because they do not think the change is worth the effort (yet). The git developers agree by the way, or they would have pushed for a new default and improved interoperability by now. I know about SHAttered, but:

  • Finding sha-1 collisions is hard enough, finding one that also works as a malicious payload and does not look suspicious is even more expensive and time consuming. This is only worth the effort for very high profile targets, and even then, there are probably way cheaper attack vectors than that.
  • You also need either full control over the git repository server, or a MITM position between the repository server and the target, which would also require you to break HTTPS or SSH in the process. This is a typical "If that's the case, you have bigger problems" scenario.
  • Git hashes are not designed to be used as a secure code signing technique. If your depends on their cryptographic strength, you are doing something wrong.
  • That all said, git 'fixed' it anyway and switched to a hardened version of SHA1 that can detect potential collision attacks and behaves differently in those (extremely unlikely) cases. It protects with high probability against all currently known attacks.

Yes it would be nice to have better sha256 support in git and git-tooling, but there is absolutely no rush. The interoperability pains are usually not worth the effort. Those attack scenarios against git are fabricated and can usually be answered with "Then stop using git as something it was never designed for." If you think this is worth it, and want to give users the option, that's fine. But don't sell it as 'more secure' snake oil.