Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.
In a well-fleshed-out post, Scott Chacon shows how unneecessary Git 3.0’s move to replace SHA-1 with SHA-256 is.
The vulnerability of SHA-1 is that it’s possible for an attacker to find colliding hashes. But that’s not really an attack vector, because it’s not like they can find aatching hash for just ANY input. In order to pull off an attack, using a hash collision, an attacker would have to already be trusted within the controlling system, in which case they can do a hell of a lot worse than swapping out a file.
Like you say, the hash is used as a lookup key within the git repo’s database. The requirement for that is uniqueness, which SHA-1 still fulfills just fine. The trust isn’t in the database lookup, the trust is in the systems that controls access to and distribution of that database.
As the article points out, Linus Torvalds himself said as much in 2005, when he first wrote git:
I really think people should not consider the sha1 the “security”. The real security is in distribution.
The blog post lays it out pretty well.
The vulnerability of SHA-1 is that it’s possible for an attacker to find colliding hashes. But that’s not really an attack vector, because it’s not like they can find aatching hash for just ANY input. In order to pull off an attack, using a hash collision, an attacker would have to already be trusted within the controlling system, in which case they can do a hell of a lot worse than swapping out a file.
Like you say, the hash is used as a lookup key within the git repo’s database. The requirement for that is uniqueness, which SHA-1 still fulfills just fine. The trust isn’t in the database lookup, the trust is in the systems that controls access to and distribution of that database.
As the article points out, Linus Torvalds himself said as much in 2005, when he first wrote git: