为什么Git不使用更现代化的SHA？
我读过关于Git使用SHA-1摘要作为修订的ID。 为什么不使用更现代版本的SHA？
更新 ：上面的问题和这个答案是从2015年。从那时起，谷歌已经宣布了第一个SHA-1碰撞： https ： //security.googleblog.com/2017/02/announcing-first-sha1-collision.html
显然，我只能从外部推测Git继续使用SHA-1的原因，但这可能是以下原因之一：
- Git是Linus Torvald的创作，Linus显然不想用另一个散列algorithm替代SHA-1。
- 他给出了合理的说法：成功的基于SHA-1碰撞的Git攻击要比实现碰撞要困难得多，并且考虑到SHA-1比它应该是脆弱的，没有完全破坏，这使得它远离至less今天是可行的攻击。 此外，他还指出，如果碰撞物体比现有物体晚到达，那么“成功”的攻击就会达到很less，因为稍后的碰撞会被假定为与有效碰撞相同并被忽略（尽pipe其他人指出相反可能会发生）。
- 更改软件非常耗时且容易出错，特别是当现有基础架构和基于现有协议的数据需要迁移时。 即使那些生产以密码安全为系统唯一点的软硬件产品的厂商，仍然处于从SHA-1等弱点algorithm转移的过程中。 试想一下，所有那些硬编码的
unsigned char[20]缓冲区遍布整个地方;对于一开始就对密码敏捷性进行编程，而不是稍后对其进行改进就容易多了。 - SHA-1的性能要好于各种SHA-2散列（现在可能不是那么简单，但可能是十年前的一个难题），SHA-2的存储容量更大。
一些链接：
- Stackoverflow的问题，如果在Git发生碰撞，会发生什么
- 新闻组的post在2005年主要的SHA-1弱点出现之后的几个月里显示了Linus对这个问题的简短评论
- 一个讨论2006年Sha-256（来自Linus的回复）的弱点和可能的举措
- NIST关于SHA-1弃用声明，并build议“快速转换到更强大的SHA-2哈希函数族”
我个人的观点是，虽然实际的攻击可能是暂时的，甚至当它们发生的时候，人们可能会首先通过除了改变哈希algorithm本身之外的手段来减轻攻击，如果你关心安全性，你应该犯错误在谨慎selectalgorithm的同时，不断修正你的安全优势，因为攻击者的能力也只朝着一个方向发展，所以以Git为榜样是不明智的。使用SHA-1并不意味着encryption安全性。
这是讨论从Mercurial迁移到SHA1的紧迫性，但它也适用于Git： https ： //www.mercurial-scm.org/wiki/mpm/SHA1
简而言之：如果你今天不是非常吝啬的话，那么你的漏洞比sha1要糟糕得多。 但是，尽pipe如此，十多年前Mercurial已经开始准备从sha1迁移出去。
多年来一直在努力改进Mercurial公司SHA1接class人的数据结构和协议。 在Mercurial 0.9中引入了RevlogNG，在10年前我们的revlog结构中为存储空间分配了更大的哈希值。 最近推出的bundle2格式支持在networking上交换不同的散列types。 唯一剩下的部分是selectreplacefunction并select向后兼容性策略。
如果在Mercurial之前git没有从sha1迁移出来，那么通过使用hg-git保留一个本地的Mercurial镜像，你总是可以增加另一个级别的安全性。
