We’ve taken a huge step in SHA-256 support in GitLab: The Gitaly project now fully supports SHA-256 repositories. While there is still some work we need to do in other parts of the GitLab application before SHA-256 repositories can be used, this milestone is important.
What is SHA-256?
SHA-256 is a hashing algorithm. Given an input of data, it produces a fixed-length hash of 64 characters with hexadecimal digits. Git uses hashing algorithms to generate IDs for commits and other Git objects such as blobs,
trees, and tags.
Git uses the SHA-1 algorithm by default. If you’ve ever used Git, you know that
commit IDs are a bunch of hexademical digits. A git log command yields
something like the following:
commit bcd64dba39c90daee2e1e8d9015809b992174e34 (HEAD -> main, origin/main, origin/HEAD)
Author: John Cai <[email protected]>
Date: Wed Jul 26 13:41:34 2023 -0400
Fix README.md
The bcd64dba39c90daee2e1e8d9015809b992174e34 is the ID of the commit and is a
40-character hash generated by using the SHA-1 hashing algorithm.
In SHA-256 repositories, everything is the same except, instead of a 40-character
ID, it’s now a 64-character ID:
commit e60501431d52f6d06b4749cf205b0dd09141ea0b3155a45b9246df24eee9b97b (HEAD -> master)
Author: John Cai <[email protected]>
Date: Fri Jul 7 12:56:52 2023 -0400
Fix README.md
Why SHA-256?
SHA-1, which has been the algorithm that has been used until now in Git, is
insecure. In 2017, Google was able to produce a hash collision. While the Git project is not yet impacted by these kinds of attacks due to the
way it stores objects, it is only a matter of time until new attacks on SHA-1
will be found that would also impact Git.
Federal regulations such as NIST and CISA guidelines,
which FedRamp enforces, set a due date in 2030 to
stop using SHA-1, and encourage agencies to move away from it sooner if
possible.
In addition, SHA-256 has been labeled experimental in the Git project for a long time,
but as of Git 2.42.0, the project has decided to remove the expe
