{"id":"53c2b47b-ebff-4269-8516-d596adcbfcbc","arxiv_id":"2607.02820","paper_version":1,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"Any signed Git commit can be malleated into a distinct hash with identical tree and metadata that still verifies and receives a GitHub Verified badge, without the private key.","lead":"Signed Git commits can be rewritten into different hashes that still verify and still earn GitHub's Verified badge, without the signing key. That breaks the common assumption that a verified commit hash uniquely names signed content for pinning, blocking, and reproducible builds.","discovery_kind":"new_application","skeptic_critique":{"model":"grok-4.5","headline":"No significant objection identified","rationale":"The reader correctly isolates the non-canonicalizing verifier behavior as the weakest assumption and correctly notes that it is already empirically confirmed by the paper’s Table 1 and live GitHub examples. Because the cryptographic primitives are classical, the Git object model is public, and the PoC tooling plus demonstration repositories make the entire chain reproducible, there is no further load-bearing technical concern that would move the verdict. Future parser hardening would reduce practical impact but would not falsify the mechanisms or the present-day observations. Therefore the ACCEPT / HIGH-confidence assessment stands without adjustment.","tokens_in":8697,"tokens_out":412,"duration_ms":3725,"concrete_test":"Clone the two public demonstration repositories (github-gpg-malleability and github-x509-malleability), run git cat-file -p and git verify-commit (or gpgsm) on both the original and malleated commits, and confirm that trees and metadata match while hashes differ and GitHub still shows independent Verified badges; success leaves the claim intact.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that any signed Git commit can be rewritten, without the private key and without colliding SHA-2, into a second object that has an identical tree and metadata, still verifies, receives a GitHub Verified badge, and therefore forces a cascade of new descendant hashes. The three routes (ECDSA s \to n-s, OpenPGP unhashed subpacket insertion, CMS non-canonical DER length) are standard malleability techniques applied to the exact bytes that Git includes inside the hashed commit object; Table 1 and the linked public repositories already show both local and server-side acceptance. The only residual uncertainty is whether forges will later canonicalize, but that is an impact-narrowing future change, not a flaw in the demonstrated mechanisms or the current evidence. No hidden assumption, encoding edge-case, or verification gap undermines the stated result.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The paper demonstrates that a signed Git commit is not a unique, immutable content identifier: without the private key and without breaking SHA-2, an attacker can produce a second commit object that has an identical tree and metadata, carries a still-valid signature, receives a GitHub “Verified” badge, and differs only in its commit hash. Three concrete routes are given—ECDSA algebraic inversion (s ↦ n−s), OpenPGP unhashed-subpacket insertion (RFC 4880 §5.2.3) for RSA/EdDSA, and non-canonical DER length re-encoding (X.690 §10.1) inside CMS/S/MIME—covering every scheme GitHub currently verifies. Because the signature bytes lie inside the hashed region, the new hash cascades to every descendant, which the authors term “hash chain malleability.” Table 1 records local versus GitHub acceptance; public PoC tooling and example repositories are supplied; and consequences for hash-based blocking, dependency pinning, and reproducible-build systems are discussed.","tokens_in":8833,"tokens_out":1212,"duration_ms":39287,"significance":"If the result holds, a widely trusted invariant of supply-chain tooling is false: a “Verified” commit hash cannot be treated as a unique primary key. The work is concrete, reproducible (Nix flake, public GitHub demos for EdDSA and S/MIME, automated graph rewriter), and rests on standard, independently specified properties rather than new cryptanalysis. Credit is due for shipping working tooling that rewrites entire commit graphs and for cleanly separating the three malleation layers. The findings directly affect Nixpkgs, Go modules, GitHub Actions pins, SLSA source track, and Sigstore/gitsign, all of which currently treat the raw commit hash as authoritative. Even if forges later canonicalize, the paper correctly documents the present state and the residual risk for any consumer that does not canonicalize before hashing.","major_comments":[{"comment":"§6 and the abstract claim that malleation of one commit “cascades” to a well-formed rewrite of all descendants while preserving the overall phenomenon of hash-chain malleability. Changing a parent hash alters the signed payload of every descendant. Because malleation only produces an alternate signature for an identical payload, the rewritten descendants lose signature validity unless the attacker possesses the signing key and re-signs. The paper never states whether the supplied rewriter (a) drops signatures, (b) leaves broken signatures, or (c) somehow preserves them. This distinction is load-bearing for the “hash chain” terminology and for any impact that assumes a fully Verified rewritten history.","section":"§6 / Abstract"},{"comment":"§5 “Bypass of immutable releases” asserts that an attacker with push access can construct a parallel chain of commits that retain “Verified” badges after force-pushing tags. For any multi-commit history the same payload-change problem arises: each rewritten descendant requires a fresh signature over the new parent list. Without the private key this is impossible. The claim therefore holds only for a single tagged commit, not for a chain. The section should be narrowed or the experimental evidence that multi-commit Verified chains can be produced should be supplied.","section":"§5"},{"comment":"§5 further claims that a malleated commit “earns its own independent log entry” in Sigstore/Rekor and thereby duplicates the SLSA/gitsign trust anchor. The provided PoCs and example repositories demonstrate only GitHub’s verifier and local git/gpgsm; no Rekor submission or SLSA provenance experiment is reported. Because the impact argument treats the independent log entry as fact, either a concrete demonstration or a clear “conjectured” qualifier is required.","section":"§5"}],"minor_comments":[{"comment":"Throughout the extracted text many words are concatenated (“pieceofsignedcontent”, “Weshowthisinvariant//ldots”). Assuming this is an extraction artifact, the camera-ready version should be checked for proper spacing and line breaks.","section":"Abstract / §1"},{"comment":"Table 1 caption and body are clear, but the column “Local” should explicitly name the tools (git verify-commit vs. gpgsm) so readers do not have to hunt in the text.","section":"Table 1"},{"comment":"§3.1 states that curve order is inferred from scalar bit length. A one-sentence note on how P-521’s non-byte-aligned order is handled would remove a minor ambiguity for implementers.","section":"§3.1"},{"comment":"Reference [7] (GitHub docs on persistent verification) is cited for the claim that records are never re-evaluated; a short quotation or archive link would make the claim more durable.","section":"§4"},{"comment":"The ethics statement lists disclosure dates in 2026 while the arXiv stamp is also 2026; a single consistent timeline sentence would avoid reader confusion.","section":"§10"}],"recommendation":"major_revision","confidential_remarks":"The technical core (three standard malleability routes applied to Git’s signed-commit serialization) is solid and the public PoCs are a genuine strength. The main defects are over-claims about full-chain signature preservation and about Sigstore/Rekor, both of which can be fixed by narrowing language or adding experiments. I would accept after those revisions; the paper is a good fit for a systems-security venue."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"The punchline is simple: a verified Git commit hash is not a unique handle for signed content. Without the private key and without colliding SHA-2, you can rewrite the signature bytes so the tree and metadata stay identical, the signature still verifies, GitHub still shows Verified, and every descendant hash changes. That cascade is what they call hash-chain malleability.\n\nWhat is new is not the crypto primitives. ECDSA s-to-n-s, OpenPGP unhashed subpackets, and non-canonical DER lengths are all known. The contribution is the clean application to Git’s object model (signature bytes sit inside the hashed region), the systematic coverage of every scheme GitHub accepts (ECDSA, RSA, EdDSA, S/MIME), the cascade rewrite of the descendant graph, and the public evidence that GitHub’s server-side verifier and durable Verified records accept all three. Table 1, the Nix flake, and the two live example repositories make the claim checkable rather than hand-wavy.\n\nThe paper does the basics well. It separates the result from hash-function collision resistance, cites the right standards (RFC 4880, X.690, BIP-62, CMS), and ships working tooling that rewrites whole chains. Impact discussion on pinning (Nix, Go, Actions), hash-based blocking, SLSA source track, and Sigstore/gitsign is concrete and proportionate.\n\nSoft spots are minor. Local verification rejects only the S/MIME route; the OpenPGP routes pass git verify-commit. The residual risk is that forges may start canonicalizing after disclosure; that would shrink future impact without falsifying the mechanisms or the current evidence. Terminology is new but not load-bearing. No circularity, no free parameters, no invented crypto.\n\nThis is for supply-chain and forge-security people, and for anyone who treats a Verified commit SHA as a content primary key. It deserves a serious referee. I would accept it for peer review and would cite the concrete result when discussing commit pinning or forge verification assumptions.","headline":"Solid, reproducible demonstration that every GitHub-supported signed-commit scheme admits keyless hash-changing malleation that still gets a Verified badge.","tokens_in":9507,"tokens_out":518,"would_cite":true,"duration_ms":4300,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"Any signed Git commit can be turned into a different hash that still verifies and earns a GitHub Verified badge, without the signing key or breaking SHA-2.","keywords":["git","commit signing","hash malleability","ECDSA","OpenPGP","S/MIME","supply-chain security","content addressing"],"falsifier":"Run the paper’s published malleator on any publicly signed commit, push the resulting ghost object to a GitHub branch, and check whether the new hash receives its own independent Verified badge while the tree and message remain byte-identical to the original.","tokens_in":9532,"feed_emoji":"⛓️","tokens_out":952,"duration_ms":18406,"temperature":0.7,"pith_summary":"Git is trusted to treat a signed commit hash as a unique, immutable name for specific content. This paper shows that trust is misplaced. An attacker who never obtains the private key can rewrite only the signature container of a signed commit so the hash changes while the tree, parents, metadata, and verification result stay the same; GitHub still awards an independent Verified badge to the new hash. Because later commits name their parents by hash, the change rewrites the entire dependent chain—the authors call this hash chain malleability. The finding matters for every system that pins, blocks, or attests by commit hash: those systems are treating a non-unique encoding as a content-addressable primary key.","feed_headline":"Signed Git commits can be rewritten to new hashes","feed_subtitle":"Same content, valid signature, and GitHub Verified badge—different hash, no private key needed.","key_machinery":"Hash chain malleability: because the raw signature bytes sit inside the hashed commit object, any change that preserves semantic signature validity changes the commit hash while leaving tree and metadata untouched. The paper supplies three concrete routes—(i) ECDSA s ↦ n−s, (ii) insertion of an unhashed OpenPGP subpacket, (iii) non-canonical DER length re-encoding in the CMS envelope—each of which GitHub accepts.","core_discovery":"Given any signed commit, an attacker without the signing key and without breaking SHA-2 can produce a second, distinct commit that carries an identical tree, identical metadata, a valid signature, and a persistent independent Verified badge on GitHub, differing only in its commit hash. The rewrite cascades through every descendant, so the entire dependent hash chain is malleable. Three routes cover every signature scheme GitHub verifies for commits: ECDSA algebraic inversion, OpenPGP unhashed-subpacket insertion, and CMS non-canonical DER length re-encoding.","pith_inferences":["Forges that canonicalize signature containers (low-s ECDSA, strip unhashed OpenPGP subpackets, enforce DER) before hashing or verification would close the attack without changing the cryptographic schemes themselves.","The same encoding gaps likely affect any other content-addressed store that embeds OpenPGP or CMS signatures inside the hashed object.","Pinning schemes that already pair the commit hash with an independent tree content hash retain a residual integrity check the pure-hash schemes lack.","The SHA-256 migration for Git object names does not mitigate the issue, because the attack never relies on hash collisions."],"forward_implications":["Hash-based blocking or reversion of a malicious commit can be silently bypassed by re-pushing a content-identical, still-Verified malleated twin.","Dependency pins that lock to a commit SHA (Go modules, Nix flakes, GitHub Actions, Dockerfiles) no longer uniquely name signed content under a given signer.","Reproducible-build and provenance systems that treat the commit hash as the primary revision identifier inherit a non-unique trust anchor.","An attacker with push access can force-push release tags onto malleated chains while GitHub continues to display Verified badges.","GitHub’s persistent verification records, keyed only by hash, allow one logical commit to appear under an unbounded family of independently Verified hashes."],"fun_headline_variants":["Any signed Git commit rewritable to new hash without private key","Verified Git commits share content yet take different hashes","Git hash chains malleable via ECDSA OpenPGP and S/MIME routes","Attackers craft twin signed commits with identical trees","Signed commit hashes lose uniqueness without key or SHA-2 break"],"cache_read_input_tokens":128,"weakest_assumption_plain":"Signature verifiers (and GitHub’s server-side checker) accept any semantically valid encoding rather than requiring a single canonical byte form before they compute the commit hash or issue a Verified record.","fun_headline_variants_meta":{"raw":{"variants":["Any signed Git commit rewritable to new hash without private key","Verified Git commits share content yet take different hashes","Git hash chains malleable via ECDSA OpenPGP and S/MIME routes","Attackers craft twin signed commits with identical trees","Signed commit hashes lose uniqueness without key or SHA-2 break"]},"model":"grok-4.5","effort":"low","cost_usd":0.008194,"raw_usage":{"total_tokens":2025,"prompt_tokens":893,"num_sources_used":0,"completion_tokens":86,"cost_in_usd_ticks":81940000,"prompt_tokens_details":{"text_tokens":893,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":1046,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":893,"tokens_out":86,"duration_ms":7754,"temperature":1.0,"reasoning_tokens":1046,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-12T06:49:24.354234+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Run the paper’s published malleator on any publicly signed commit, push the resulting ghost object to a GitHub branch, and check whether the new hash receives its own independent Verified badge while the tree and message remain byte-identical to the original.","supporting_citations":[],"review_version":1}