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.

#hashing #security vulnerabilities #dvcs #git #development #news