@nprofile1q... Interesting. I'm not sure that I understand the problem in [the paper](
https://arxiv.org/pdf/2607.02820) though. From the introduction:
>Git identifies every object by the hash of its serialized content. For a commit, this hash covers the tree, the parent list, author, and committer metadata, the commit message, and—crucially—the raw bytes of any embedded signature. Because the hash is a deterministic function of these bytes, the commit hash is routinely relied upon as a globally unique, immutable, content-addressable identifier: CI pipelines pin to them, dependency managers lock to them, and incident-response tooling blocks or reverts by them
>
>...
>
>Digital signature schemes oftentimes admit malleability: given a valid signature, one can often derive a second, syntactically distinct signature that verifies against the same message and key without knowledge of the private key. Applied to a signed commit, malleation changes the signature bytes, and hence the commit hash, while preserving both the content and the verification result.
I mean... okay? The signature bytes --- which are part of the content --- are changed. Ergo, the "content" is indeed still:
(1) uniquely, and
(2) immutably
addressed. The abstract argues:
>Git commit signing is widely entrusted to serve as evidence that a commit hash uniquely and immutably identifies a specific piece of signed content. We show this invariant does not hold.
And the introduction further argues:
>We observe that these are not merely local parser quirks: Github’s server-side verifier accepts malleation for all of the aforementioned signature schemes, and its persistent verification record [7], keyed on commit hash, produces multiple independent “Verified” entries for the same content (§4).
But it's **not** the "same content". The signature bytes are different. The invariant **does** hold.
The main complaint seems to be that "folks are assuming there can only be one hash for $content_but_without_signature", **and** that this... breaks something?
Their [github repository](
https://github.com/JakeGinesin/git-chain-malleator) seems to imply that this causes problems because:
>Nixpkgs / any hash-pinning system: trust in `hash(commit)` as a unique handle is likely unreliable; the same signed content produces N valid `Verified` hashes
But I don't think those kinds of consumers are relying on the commit id (or a hash of it) to be a **unique** handle of the contents **without the signature**. And if they **are**, then... that's a misunderstanding of what Git is doing, and the **consumer** needs to adjust their data model and/or code. There's nothing for Git, itself, to "fix" here, as the authors lament in their conclusion:
>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.
The GitHub repository seems to imply that deduplication efforts based on the commit id are "vulnerable", but they are only vulnerable in the sense that they'd end up storing multiple copies of the $content_but_without_signature. That $content_but_without_signature has not been compromised; whatever else was in the commit is still identical.
#git #cryptography
