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.
Even if it’s not the purpose it can fulfill it. Hashes are used for all kinds of things like traceability or for pinning versions. They are used in a context where people depend on that a hash always has the same code behind it and SHA1 can not guarantee that anymore. A better hashing algo is needed to keep the way how people use git secure.
It’s not enough to say “you shouldn’t use it that way”. We have to accept the reality of how git is used and adapt.
If someone has access to write to a repo you are downloading code from, and you don’t trust that someone, you shouldn’t be running the code in that repo.
The only “security” vulnerability is: I have audited and verified that the code in commit 05682ab36ca. And I will use only that version.
What you do then is: download that commit and store it in a local repo, and package it so you can distribute it to your clients.
Auditing external software is tremendous effort, even if it is open source. Using your local repo instead of downloading that commit from GitHub every time is very little extra effort in comparison.
And if you really need it. You can always hash with sha256 yourself and verify that the commit with that sha1 still produces the same sh256. So you can keep downloading it each time, just need to store the sha256.
You are exactly doing what I described. You are saying “your using it wrong” instead of acknowledging that’s how people use it and and then improving that. You might not need this feature because you are “using it correctly” but that doesn’t matter. For the lived reality of many people sha256 is the correct move.
I have. In some languages you can use git repos as dependencies. It’s good practice to use hashes instead if tags because tags are not immutable. SHA1 hashes are better than tags but better hases would be even better.
Also traceability. You can build a chain from your commit over ci to the artifact if you do it right. If you can change the files to a hash you can destroy that trust chain. Sha256 makes that impossible.
People use the hashes in ways you might not. It wasn’t meant as a trust anchor but it became one. And that is now being addressed. I also think that the git maintainers have put a lot of thought into backward compatability and making the change as painless as possible.
Good practice != Something that ensures security. As I said, it’s an even better practice to just host your own fork if what you want is security. The reason to use git hashes is mostly so you don’t have to trust the author following semver in there version number. It’s a matter of ensuring that your code will always compile, not a security feature.
Have you read the article? Your arguments derive from an assumption of “sha1 is mutable, sha256 is immutable”. First of all, every hashing algorithm is going to have collisions, that’s an unavoidable “feature” of hashes. And sha1 is in no way “mutable”, it takes a great amount of effort (and money) to generate a collision. Furthermore, those collisions are not arbitrary. You have to calculate them beforehand. As the article says: what is more likely? Paying 40k€ in compute time to generate a single collision? Or just paying an open source maintainer 40k€ to let you do 1 new commit that most people are going to download anyway?
Even if it’s not the purpose it can fulfill it. Hashes are used for all kinds of things like traceability or for pinning versions. They are used in a context where people depend on that a hash always has the same code behind it and SHA1 can not guarantee that anymore. A better hashing algo is needed to keep the way how people use git secure.
It’s not enough to say “you shouldn’t use it that way”. We have to accept the reality of how git is used and adapt.
If someone has access to write to a repo you are downloading code from, and you don’t trust that someone, you shouldn’t be running the code in that repo.
The only “security” vulnerability is: I have audited and verified that the code in commit 05682ab36ca. And I will use only that version.
What you do then is: download that commit and store it in a local repo, and package it so you can distribute it to your clients.
Auditing external software is tremendous effort, even if it is open source. Using your local repo instead of downloading that commit from GitHub every time is very little extra effort in comparison.
And if you really need it. You can always hash with sha256 yourself and verify that the commit with that sha1 still produces the same sh256. So you can keep downloading it each time, just need to store the sha256.
You are exactly doing what I described. You are saying “your using it wrong” instead of acknowledging that’s how people use it and and then improving that. You might not need this feature because you are “using it correctly” but that doesn’t matter. For the lived reality of many people sha256 is the correct move.
I’ve never heard of anyone relying on git’s sha1 hashed for security
I have. In some languages you can use git repos as dependencies. It’s good practice to use hashes instead if tags because tags are not immutable. SHA1 hashes are better than tags but better hases would be even better.
Also traceability. You can build a chain from your commit over ci to the artifact if you do it right. If you can change the files to a hash you can destroy that trust chain. Sha256 makes that impossible.
People use the hashes in ways you might not. It wasn’t meant as a trust anchor but it became one. And that is now being addressed. I also think that the git maintainers have put a lot of thought into backward compatability and making the change as painless as possible.
Good practice != Something that ensures security. As I said, it’s an even better practice to just host your own fork if what you want is security. The reason to use git hashes is mostly so you don’t have to trust the author following semver in there version number. It’s a matter of ensuring that your code will always compile, not a security feature.
Have you read the article? Your arguments derive from an assumption of “sha1 is mutable, sha256 is immutable”. First of all, every hashing algorithm is going to have collisions, that’s an unavoidable “feature” of hashes. And sha1 is in no way “mutable”, it takes a great amount of effort (and money) to generate a collision. Furthermore, those collisions are not arbitrary. You have to calculate them beforehand. As the article says: what is more likely? Paying 40k€ in compute time to generate a single collision? Or just paying an open source maintainer 40k€ to let you do 1 new commit that most people are going to download anyway?