The latest version of Git experimentally enables using SHA-256 instead of SHA-1 for file hashing, thus removing a long-standing vulnerability which in principle allowed an attacker to forge a counterfeited repository with a head not distinguishable from the original's.
As is well-known, Git has been using SHA-1 to calculate a hash for each commit:
For example, files, directories, and revisions are referred to by hash values unlike in other traditional version control systems where files or versions are referred to via sequential numbers.
Anomg other advantages, Git's approach makes integrity checks trivial, since corrupted content will not hash to the same value Git stored in the first place. Unfortunately, SHA-1 has long been known to be vulnerable and a few years ago a group of researchers showed it was less secure than initially thought by devising an attack that crafted two PDF files with different content but equal hash. They also noted Git was specifically at risk:
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.
Since then, the Git team has been at work to harden their SHA-1 implementation by attempting to detect whether an object was crafted with the intention of producing a collision and then rejecting it. While this made it less prone to being exploited, transitioning to a new, more secure hashing algorithm, such as SAH-256, was no small feat that required lots of analysis and design.
In short, Git introduced a new repository format using SHA-256 for both object names and content. This new format also provisions a bidirectional mapping between SAH-256 and SHA-1 names that is generated locally and that makes it possible to refer to object using either their SHA-1 and SHA-256 names interchangeably.
This approach makes it possible for a SHA-256-enabled client to interoperate with an older SHA-1 server. When fetching SHA-1 hashed content, a modern client will automatically generate its SHA-256 form; conversely, when pushing it will convert its SHA-256 objects to SHA-1 so the server does not need to know which hashing algorithm the client is using.
As important as this new development may sound, it is important to stress there is no interoperability between SHA-1 and SHA-256 repositories yet. Additionally, no major Git provider, including GitHub, is currently supporting SHA-256-enabled repositories yet nor has announced a plan to do.
As usual, Git releases are packed with changes, including bug fixes, performance improvements, and new features. Do not miss the official release notes for the full details.
