Commit Author Spoofing

What Is Commit Author Spoofing?

Commit author spoofing exploits a simple fact about Git: the author name and email on a commit come from local configuration, and anyone can set them to any value. Git copies those values verbatim, so a commit can claim to have been written by any person, and the author field alone proves nothing about who really made the change. Only a cryptographic signature, from GPG or SSH, actually ties a commit to a real key and a real identity. This is an integrity and authorship attack, distinct from secrets leaking out of a repository: nothing here is exposed, but a change is falsely attributed. This exercise puts you on both sides. As Bob, a contractor at the payments company Voxmere, you already have push access to the shared integration branch, but nothing ships until a maintainer reads that branch's log and promotes it. So you read the maintainer's exact name and email straight out of the repository's own history, set them with git config, and commit a one-line change that cuts the webhook signature comparison down to eight characters, leaving forged payment events easy to sign. The commit lands on the branch wearing her name. As Alice, the staff engineer who runs that promotion, you pick up the investigation when the maintainer reports a commit she never wrote. You find her name, address, and avatar on it, the signature badge reading Unverified, and a signature log showing that her genuine commits verify against her key while this one carries nothing at all. You revert the change, then require signed commits on the branch with no administrator bypass, and confirm the fix by attempting the same push again and watching the server reject it. The exercise closes with quiz questions on why an author name cannot be trusted, what makes a commit verifiable, how the attacker found the identity to borrow, and why visible signature badges stopped nothing until signing was enforced.

What You'll Learn in Commit Author Spoofing

• Recognize that a commit's author name and email are self-asserted local Git configuration that anyone can set, so the author field is a label, not proof of identity
• See how a spoofed author borrows a trusted maintainer's name so a malicious change reads as routine in the branch log a reviewer scans before shipping
• Understand that author emails are published in every commit and travel with every clone, so an attacker can read the identity to impersonate straight out of the repository
• Distinguish a Verified commit, backed by a cryptographic signature, from an Unverified commit whose author field is unproven
• Apply the fix: require signed commits on shared branches, with no administrator bypass, so the server rejects unsigned work instead of relying on someone noticing a badge

Commit Author Spoofing — Training Steps

1. The branch he can already push to

   Today Bob is targeting Voxmere, a payments infrastructure company where he works as a contractor. His contract gives him push access to ledger-core's shared integration branch, which is normal: that is where contributors stage work. What he does not have is a way to make anyone trust it. Nothing on integration ships until a maintainer reads the branch log and promotes it into main.

2. Clone the service

   Bob clones ledger-core, the service that handles every settlement, refund, and reconciliation path at Voxmere. He has read access as a contractor, so this is an ordinary working checkout.

3. Read the names out of the history

   Bob needs the maintainer's exact author identity, and he does not have to guess or phish for it. Every commit ever made carries its author's name and email, and the log will print them on request. One name repeats far more than the others. Dara Whitlock is the maintainer whose changes go through without argument, so hers is the identity worth borrowing.

4. Borrow the name

   Bob points his local Git configuration at Dara Whitlock. There is no challenge, no verification, and no confirmation: the command sets a string, and Git believes it.

5. Borrow the address

   Now the email. This one matters more than the name: the forge matches a commit's author email to a user account, so from this point on Bob's commits will render with Dara's profile and her avatar attached to them.

6. The webhook verifier

   Bob opens the file he came for. Every payment event that reaches the ledger arrives as a webhook signed by the processor, and this function is what decides whether that signature is good. Right now it compares the full digest, in constant time. It is correct.

7. Shorten the comparison

   Bob changes one line. The comparison still runs, still uses the same helper, and still looks like signature verification. It just stops after the first eight characters. He writes it as a performance tweak, because that is what it looks like.

8. What eight characters costs

   A full signature is sixty-four hex characters. Comparing eight of them leaves thirty-two bits, which is a few seconds of guessing. Anyone who can reach the webhook endpoint can then sign whatever payment events they like, and the ledger will accept every one of them as genuine.

9. Commit under the borrowed name

   Bob commits. He does not pass a flag, override anything, or use a special command: the identity he set two steps ago is simply what Git stamps onto the commit.

10. Read it back

    Bob checks his work. The commit he just made reports Dara Whitlock as its author, with her address beside it. There is nothing in the output marking it as unusual, because from Git's point of view nothing unusual happened. It recorded the identity it was given.