Git Hash Chain Malleability

java-man

> We complied with standard responsible disclosure procedure throughout this work. We initiated responsible disclosure with GNU and Git on Jan 16th 2026, as well as Github on March 3rd 2026; as of writing, unfortunately this issue has failed to be addressed by Git nor any Git forge.

smitop

I don't think this is really a problem; I wrote about my thoughts at https://iter.ca/post/git-malleate/

logological

> We complied with standard responsible disclosure procedure throughout this work. We initiated responsible disclosure with GNU and Git on Jan 16th 2026… Why would the author have disclosed the issue to GNU? As far as I know, they don't have anything to do with the development of Git. Perhaps it's because they run a Git server for their Savannah forge, but then again, so does pretty much every other forge out there, most of which are far more widely used.

woodruffw

> Systems that pin to commit hashes (e.g. Go module proxies, Nix flake locks, Github Actions references, Dockerfiles naming a specific commit, etc) rely on the assumption that a hash is a unique handle for content under a given signer. I don’t think this is true on either count: systems that pin to commits frequently don’t look at commit signatures at all, and there is no particular assumption of uniqueness between object IDs and contents (given that object IDs can point to each other across namespaces, e.g. a tag reference that peels to a commit). (I also agree with the points below about this probably not being a useful form of malleability: there are a nearly infinite number of ways to “malleate” janky encodings like GPG packets and CMS. The much more interesting malleability is when an attacker forges a signature over contents the victim did not intend to sign, which is not demonstrated.)