Folklore runs deep in the software world. You wouldn't think so, A world composed of people who need unit tests to verify anything. Where any post on Hackernews is full of comments questioning the validity of the original post. A world where zero trust is such a common buzzword. Yet we have all heard stories of people gaming the system to their advantage in unconventional ways. Nod along if you are familiar with any of these.

• The person who has automated their entire job without letting anyone know.
• Mouse jigglers to stay active on Slack.
• Nerf turrets controlled by Jenkins failures.
• Bash script to tell the office coffee machine to start making his coffee.

Honestly, I have heard all of these and so many more. Who knows if any of these stories are true, I have never seen anything on this sort of scale at least. But the world is big, and if my old office coffee machine had an api. I would use it.

This is a true story, one about an overreaction to a series of events. That overreaction was driven by another folklore story. Ever heard the one about the dev who hired somebody cheaper to do their work? I have. So when a new hire made their first pull request, and somebody else showed up in the commit log. Alarm bells started to blare in Slack channels, senior decision makers were made aware, and very quickly access had been cut.

So what really happened? Well, for that we need to look at how some of the tools we use play together, let's dive in.

Git is old

21 years old to be exact (according to wikipedia, it was released April 7, 2005).

Anyway, git was not built with modern, online security standards, how could it have been, it's 20 years old. When you log onto Github, Bitbucket, or whatever you may use, and you view commits from your account. That is all tracked by the website, or host if you will, not git itself. Whoever is hosting the repository has to carefully add these security features you know and expect.

Can I access a repository? Can I push to a repo? All of this is enforced by the host, not git itself. The host will use whatever means it feels necessary to allow people to identify themselves (ssh keys, personal access tokens, yada, yada...). But none of this is git, and after you clone a repository and have it on your computer, that's all you have, just git!

However, git does have a method of tracking who did what. Take a look at a git config file, and you will see lines like.

user.name=Ian McNaughton
user.email=IanMcNaugh@gmail.com

These values will be added to any commits you make to help track who did what. Most of us never even pay attention to these configs anymore. Set them once globally when you first get your computer and never think about it again. Unless, of course, you think of these configs so little that you forget to set anything before making changes and are gently reminded by git itself.

But there are no rules here. There are no accounts, no JWT tokens, or anything fancy, just two strings, name and email. Want to be known as Beff Jezos with an email of Beff@Mamazon.Jezos? Your colleagues might look at you funny, but go right ahead! And when you push your code up to Github, your SSH key is verified and your Github account identified. Will Github correct this for you? No! How could it? It has no idea what has happened to that repository since it was pulled down.

Yes, you can sign your commits, and yes, Github will attempt to take the email the commit was made with and find a public key to verify the signature. The root issue is still present. Anyone can change their local git configs to mimic anyone else.

What's a Github to do?

Github, and every other repository host for that matter, has a problem. How do you show what account made what commit? Well, it turns out that Github will use your email to match commits up to an account. Now keep in mind, anyone can set the email in their git config file. So if I change my git email to Sergey Brin's and push that commit, he gets credited with the commit¹.

What I did not know at the time, and am still confused by. Github allows you to register multiple emails to your account, and you don't even have to verify the email address for commits to be matched to your account. How this is allowed, I can't say. You can add the email billGates@microsoft.com to your account, and commits will start appearing in your name².

The Resolution

After an investigation, many apologies, and a quick fix to a git config file, things are good. Turns out the new hire had gemini-cli@google.com set in their git configs. A simple and harmless mistake, most likely snuck in by some coding agent while debugging an unrelated issue. The email had been registered to the account of a new grad from Karachi, Pakistan, not the person we knew as the new hire. Github gladly matched the account and displayed it as the author of a new pull request in our private repository, and for a while that folklore looked a lot more like reality than a ghost story.