Re:Git 3.0's upcoming SHA-256 default will be a costly mistake
by kazinator on Friday October 02, 2026 @08:31AM
(#49932758)
You are not saying anything other than that hashes are useful for signing. When you communicate to someone that you trust such and such a hash, and they should too, you are informally certifying the hash, the cryptographically formal way to do which is to sign it.
Re:Git 3.0's upcoming SHA-256 default will be a costly mistake
by lxgr on Friday October 02, 2026 @08:50AM
(#49932949)
> You are not saying anything other than that hashes are useful for signing.
Yes, but you seem to be saying they are not, or maybe just that git hashes are somehow inherently not capable of taking that role, unless I'm misunderstanding.
Yes, they ought to be good enough. That has always been git's security model.
Note that the commit doesn't have to be communicated over the same channel as the git data.
> Well, what about someone who is fetching the commit from that server for the first time and has nothing to compare the hash against?
Then they're vulnerable. But what about somebody learning about the trusted hash in another way, e.g. a build server getting an internal call authenticated by an authorized developer?
Just because you can think of an insecure way to use git hashes doesn't mean there aren't any other, secure ones.