Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.
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.
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.
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.
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.
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.
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.
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.
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.