InfoQ Homepage News Git 2.29 Introduces Experimental Support for SHA-256

Git 2.29 Introduces Experimental Support for SHA-256


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 an head not distinguishable from the original's.

As it 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 reject 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 provision 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 detail.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.