Re:Git 3.0's upcoming SHA-256 default will be a costly mistake
by kazinator on Friday October 02, 2026 @11:26AM
(#49934584)
Well, no, you cannot because under this system, you can't prove anything about some other commit; the history is not trusted.
You can produce two commits that have the same SHA-1 and hash them. One has the vulnerability and one doesn't.
Then someone else bases a new commit on the one with the vulnerability, which has yours as the parent. You then swap in the one without the vulnerability and now it looks like the child is introducing that change.
Their only defenses are (1) plausible deniability (we don't trust parent hashes) and (2) still having the original commit they based theirs on to show that a swizzle took place and that the real original already had the vuln.
You can produce two commits that have the same SHA-1 and hash them. One has the vulnerability and one doesn't.
Then someone else bases a new commit on the one with the vulnerability, which has yours as the parent. You then swap in the one without the vulnerability and now it looks like the child is introducing that change.
Their only defenses are (1) plausible deniability (we don't trust parent hashes) and (2) still having the original commit they based theirs on to show that a swizzle took place and that the real original already had the vuln.