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.
Very interesting. I taught git to students last year and was showing them the SHA256 option and the issues he’s describing was pretty much what I was wondering about. If you force people to switch, with no intercompatibility, holy shit this is gonna be quite the clusterfuck!
What I’m taking away from this is that Linus was right from the get go : SHA1 isn’t there for security, it’s a really good algorithm for a hashtable’s hash where we really want to avoid collisions. That’s it.
If you’re thinking it’s safe because it used to be involved in security, you’re a muppet.great read, thanks for sharing!
Migrations like this are a good reminder to write down why a default changed. Junior devs often skip reading the design discussion, but it teaches more than the release notes.
Good thread. For mentees learning git, I would start with a clear branching habit before worrying about hash internals.
I don’t really understand why they didn’t switch to SHA-3 at this point
Can’t argue with that! The fact that you cant mix and match within a repo means this should be a complete non-starter.
Why not blake3?
Addressed in the article.
Where?
The attack is vague and unlikely, but blak3 might be faster. Of course less support than sha256
