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.
Which are? I’m not joking, “GitHub broken” and “Google has issues” are not arguments against a better encryption default.
The submodule argument is transitional at best.
As for the pro side (note that this is my opinion, I’m not deeply involved in the discussion - and with not deeply I mean “not at all”):
The case the author aggressively ridiculed ("I don’t use GPG to trust, I trust the GitHub authentication!) is one that anyone would have if they’d want to stay safe from centralized systems.
Another is upstream availability: once an algorithm is identified as broken (no matter how small) usage drops rapidly - there’s a reason why no one uses md5 anymore although it “would be fine” for purely collision mitigation.
And then there the simple fact that the integrity hash is a security feature, not purely anti collision (as the author also describes). Just because they (nor I!) can’t see an attack vector at the moment doesn’t make this less of an issue.
In short: it’s the other way around: you’d need way stronger arguments than “there will be a transition pain” to knowingly compromise your security.
I still like md5 for collision detection, but every damn security scanner flags it. So then you have to add the exception, then explain to auditors about the exception. It’s not worth the hassle for the increased performance.
There’s no reason to use md5 if you don’t care about security and only want speed. Non-cryptographic hashes are incredibly fast to calculate and there are far faster hashing algorithms if you want to go that route. Using md5 is a “I don’t want to think hard” answer, and if you don’t want to think hard, then you might as well be secure in your default answer.
There are some very good points in there, I would like to hear the counter-arguments.
Which are? I’m not joking, “GitHub broken” and “Google has issues” are not arguments against a better encryption default.
The submodule argument is transitional at best.
As for the pro side (note that this is my opinion, I’m not deeply involved in the discussion - and with not deeply I mean “not at all”):
The case the author aggressively ridiculed ("I don’t use GPG to trust, I trust the GitHub authentication!) is one that anyone would have if they’d want to stay safe from centralized systems.
Another is upstream availability: once an algorithm is identified as broken (no matter how small) usage drops rapidly - there’s a reason why no one uses md5 anymore although it “would be fine” for purely collision mitigation.
And then there the simple fact that the integrity hash is a security feature, not purely anti collision (as the author also describes). Just because they (nor I!) can’t see an attack vector at the moment doesn’t make this less of an issue.
In short: it’s the other way around: you’d need way stronger arguments than “there will be a transition pain” to knowingly compromise your security.
I still like md5 for collision detection, but every damn security scanner flags it. So then you have to add the exception, then explain to auditors about the exception. It’s not worth the hassle for the increased performance.
There’s no reason to use md5 if you don’t care about security and only want speed. Non-cryptographic hashes are incredibly fast to calculate and there are far faster hashing algorithms if you want to go that route. Using md5 is a “I don’t want to think hard” answer, and if you don’t want to think hard, then you might as well be secure in your default answer.
Can it be classified as a security feature if there is no identified security benefit?