GitHub 'Verified' Commits Can Be Rewritten Into New Hashes Without Breaking Signatures

Summary

A security flaw allows attackers to create new, valid signatures for existing Git commits without the original signing key, leading to the same files and metadata but a different hash. GitHub still marks these malleated commits as 'Verified,' undermining systems that rely on commit hashes for deduplication and provenance. The issue stems from forges not normalizing signatures before verification, a problem with historical parallels in Bitcoin.

Key Takeaways

1. A signed Git commit's hash can be rewritten into a new hash with a valid signature, even by someone without the original signing key, and GitHub will still stamp it 'Verified.'
2. This malleability allows attackers to bypass blocklists by re-pushing the same content under a fresh, still-'Verified' hash, impacting deduplication, provenance logs, and reproducible-build records.
3. The flaw lies in how forges (like GitHub) decide what 'Verified' means, specifically by not normalizing signatures before checking them, and the fix belongs on the forge's side.

Statement Breakdown

• Claimed Facts: 60% of statements the article presents as facts
• Opinions: 30% of statements classified as editorial or subjective
• Claims: 10% of statements surfaced for additional reader evaluation

Credibility & Bias Reasoning

Credibility assessment: The article presents technical research and findings from a PhD student. It clearly distinguishes between what is and isn't a vulnerability, and cites specific cryptographic methods. However, it relies heavily on the researcher's paper and lacks direct commentary from the platform (GitHub) or other independent security experts.

Bias assessment: Technical Explainer. The article focuses on explaining a technical vulnerability in Git commit verification. It avoids emotional language and presents the findings objectively, attributing them to the researcher. The primary goal is to inform about a security flaw rather than persuade on a particular viewpoint.

Note: This article delves into a technical security vulnerability. While it presents research findings, consider cross-referencing with official statements from affected platforms or independent security analyses for a broader perspective.

Credibility flag: Technical Deep Dive

Claimed Facts (10)

• This is presented as a direct consequence of the research findings.
• This is a direct statement of fact about the discrepancy caused by the malleability.
• This describes a potential attack vector enabled by the vulnerability.
• This identifies the researcher and their credentials, presented as factual information.
• This provides details about the research output and accompanying tools.
• This describes a specific technical consequence of malleating a commit chain.
• This is presented as the direct technical reason for the observed behavior.
• This lists the specific cryptographic schemes affected by the vulnerability.
• This explains how GitHub's verification process contributes to the issue.
• This clarifies a potential misunderstanding about the nature of the vulnerability.

Opinions (10)

• This statement expresses the significance of the issue, which is a subjective interpretation of its impact.
• This is a prescriptive statement about where the solution should be implemented.
• While based on observation, the phrasing 'one enabler' suggests an interpretation of causality and importance.
• The phrase 'To be clear' indicates an effort to guide the reader's understanding, implying a potential for misinterpretation.
• The word 'old' is a subjective assessment of the novelty of the technique.
• This is a comparative judgment on the complexity and novelty of the fix.
• The word 'simple' is a subjective assessment of the advice.
• This is an assertion of the continued relevance of previous advice.
• This is a comparative statement about the scope of the current research's implications.
• The phrase 'caution against leaning too hard' and the subsequent explanation represent an interpretation and advisory tone.

Claims (10)

• This is a broad generalization that might not hold true in all review scenarios, and it's presented without specific evidence to support its universality.
• While true in the context of malleability, this is a stark, unqualified statement that could be misleading without the preceding context of the vulnerability.
• This is a definitive negative claim that, while likely true for the core signature check, might oversimplify the potential for misuse or confusion in broader workflows.
• The assertion that 'nothing to change in your own repo' is a strong claim that might not account for all user configurations or mitigation strategies. The definitive statement about the fix belonging solely on the forge's side is also a strong opinion presented as fact.
• This is a strong, unqualified claim about covering 'every' scheme. While likely based on the research, absolute claims in security can be prone to exceptions.
• While the tool's reproduction is stated, the claim that GitHub 'still marks it "Verified"' is presented without direct evidence from GitHub itself, relying on the tool's output as proof.
• The phrase 'rhyme with that' is metaphorical and not a direct technical explanation of the fix, making it less precise.
• While the paper may connect these, the direct assertion of connection without detailing the nature of the connection or the paper's specific reasoning can be seen as a claim that requires further substantiation.
• Calling the advice 'simple' is a subjective assessment and might downplay the complexity or effort involved for users.
• This is a comparative statement that lacks specific metrics or evidence to quantify how much 'narrower' the point is compared to previous discussions.

Key Sources

• The Hacker News — Media
• Jacob Ginesin — PhD student at Carnegie Mellon University and cryptographic auditor at Cure53
• Carnegie Mellon University — University
• Cure53 — Cybersecurity Auditing Firm
• GitHub — Platform
• GNU — Software Project
• Git — Version Control System