Re:Git 3.0's upcoming SHA-256 default will be a costly mistake
by lxgr on Friday October 02, 2026 @09:11AM
(#49933179)
> It's like, imagine you made a "bill of materials" of your project's files consisting of their names and CRC-32 checksums, and then signed this file, and called your project securely signed, LOL.
If you are arguing that CRC-32 is a cryptographically secure hash function you might.
SHA-1 is (or rather, used to be) one, so you actually can. This is literally how git works.
> It's really sneaky that the SHA-1 business (not intended to be a security mechanism) was embroiled into the signing implementation; that GPG is demoted to the strength of SHA-1.
What's sneaky about it? It's a completely reasonable design decision, making git orders of magnitude more efficient than the counterfactual you're arguing for.
> Was that just to save some cycles? It's certainly faster just to sign the commit object!
Sure, "just" read potentially gigabytes of data, potentially over the network, and send them through your cryptographic hash function as opposed to just the objects you're touching in your commit. Absolutely the same effort.
If you are arguing that CRC-32 is a cryptographically secure hash function you might.
SHA-1 is (or rather, used to be) one, so you actually can. This is literally how git works.
> It's really sneaky that the SHA-1 business (not intended to be a security mechanism) was embroiled into the signing implementation; that GPG is demoted to the strength of SHA-1.
What's sneaky about it? It's a completely reasonable design decision, making git orders of magnitude more efficient than the counterfactual you're arguing for.
> Was that just to save some cycles? It's certainly faster just to sign the commit object!
Sure, "just" read potentially gigabytes of data, potentially over the network, and send them through your cryptographic hash function as opposed to just the objects you're touching in your commit. Absolutely the same effort.