69
Git 3.0's upcoming SHA-256 default will be a costly mistake
(blog.gitbutler.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Oct 2026
69 points (91.6% liked)
Git
4842 readers
8 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 3 years ago
MODERATORS
The author makes the argument that we shouldn't update the hashing algorithm because an adversary has simpler, cheaper means to achieve the same goal of injecting malicious code into a project. I don't find this a convincing reason. People say the same about Wayland. As I understand it, Wayland makes it so that processes can't see inside windows in other processes or observe the keyboard when one of its windows is not in focus, something X11 apparently doesn't guarantee. They say we shouldn't switch because it would achieve nothing: an adversarial program could just as easily do similar snooping because it has access to the user's home directory. I think that just means we need to also patch the other holes. You can't improve security by doing nothing. It's like you have two insecure doors in your home and you don't bother installing a lock on one because an intruder could easily get through the other one. You have to start somewhere. You can strengthen the hashes and try to patch the other holes (social engineering, etc.) at a later point.
he gives a pretty reasonable solution at the end? basically his point is the implementation is problematic and causes churn for everyone who uses git and if the concern is really about security then they would allow swapping out the verification hash instead of hard coding it again and waiting for 256 to be broken.
Wayland actually increases the barrier to entry by improving the security model.
Git commit hashes were never meant for security or trust, and trying to crowbar them into that role is shortsighted, as Linus argues.
Personally, I'm in favor of the migration and would already be using it (except Nix only supports sha1 atm). But, the security argument isn't a good one.
I'm in favor of a better hashing algorithm because the hash will be a better hash, not because I think it will improve the cryptographic security and trust of my repos. But honestly, that's just a nerd mental thing. I could take it or leave it. SHA1 is sufficient for the role.
I don't think your Wayland comparison is great. There are already solutions to app isolation that make X a weak link, e.g. Android or Qubes. Whereas there's basically no future where SHA1 in Git is the weakest link.
Also security was only one reason for Wayland.