Skip to content
PrivateAI
← Back to Home
privacy guides

The Developer Identity Leak: Your Email Is Embedded in Every Commit You've Ever Pushed

11 min read min readBy PrivateAI Team

Last updated: 2026-05-22

You've put real thought into your AI privacy posture. Local models, no-logs VPN, encrypted DNS. Your prompts stay on your machine. Your documents don't leave your filesystem. You know which vendors to trust and which to avoid.

Now run this command:

```bash

git log --format="%ae" | sort -u

```

That's every email address that has ever appeared in your commit history. If you've been using your personal or work email without thinking about it, that list is now permanently embedded in every repository you've ever pushed — public or private, on GitHub, GitLab, and every clone that has ever existed.

This is not a theoretical risk. It is one of the most consistent, overlooked privacy leaks in a developer's workflow, and it operates completely independently of how carefully you've hardened everything else.

Why Git Commits Are a Permanent Record of Your Identity

Git is designed to be immutable. Every commit is a cryptographically hashed object that includes, among other things, the author.email and committer.email fields. These get set once — when you run git commit — and they cannot be changed without rewriting history.

Rewriting history on a private repository you control is possible but tedious. On any repository where other people have cloned or forked your work, it is effectively impossible. The old commits exist on every copy, and there is no mechanism to propagate a history rewrite across the distributed system.

What this means in practice:

  • Every open source project you have ever contributed to contains your email, forever, in the git log.
  • Every public repository you have ever created has your email embedded in every commit.
  • Every pull request you have ever merged records your email in the merge commit.
  • Even in private repositories, the email is there — waiting for the day the repo becomes public, gets archived, or gets subpoenaed.

GitHub does expose commit emails in several ways: via the API (/repos/{owner}/{repo}/commits), in .patch files generated from PRs, and in the web UI for any public repository. Any automated scraper that has indexed GitHub's commit history — and there are many — has your email.

The npm and PyPI Problem Is Worse

If you publish packages, your exposure extends beyond git logs into permanent, indexed package registries.

Every package published to npm includes a package.json with an author field. The npm registry API exposes this publicly and indefinitely. Even if you deprecate or unpublish a package (which npm restricts after 72 hours anyway), cached versions exist across mirrors, CDNs, and registry proxies worldwide.

```json

{

"name": "your-package",

"author": "Your Name ",

...

}

```

PyPI has the same structure. RubyGems. Crates.io. Packagist. Every major language ecosystem has a public registry that stores maintainer emails, and most of them have been scraped, archived, and indexed by third parties for years.

The data brokers who build developer profiles — used by recruiters, sales teams, competitive intelligence firms, and less savory actors — know this. "Find the email for the developer who maintains X library" is a solved problem. The answer is in the git log or the package manifest, and it has been there since the first version was published.

What Someone Can Do With Your Developer Email

Your email address is more than a contact method. It is an identity anchor that connects your professional and personal life in ways that are difficult to untangle after the fact.

Account enumeration. Most authentication systems use email as a username. Knowing your email address means someone can check whether you have an account on any given service, often without triggering any alert on your end. This is used for targeted phishing: attackers confirm you use a service, then send convincing fake notifications from it.

Credential stuffing. If your developer email appears in any of the major breach datasets — Have I Been Pwned currently tracks over 13 billion breached accounts — attackers have a starting point. Even if you use strong unique passwords everywhere, knowing your email narrows the attack surface.

Social engineering. Your email appears next to your commits, which reveal your coding patterns, the projects you work on, the companies you contribute to, and roughly when you are active. A targeted social engineering attempt built on this information can be highly convincing.

Data broker aggregation. Data brokers cross-reference email addresses across public records, social networks, and breach databases to build remarkably complete profiles. Your developer email, if it is also your personal email, ties your professional work to your home address, family members, phone number, and financial records.

None of this requires a sophisticated attacker. The data is publicly accessible and the tools to aggregate it are widely available.

GitHub's Noreply Email: Helpful, But Incomplete

GitHub recognized the commit email problem and introduced a privacy option: if you enable "Keep my email address private" in settings, GitHub will substitute a noreply address (username@users.noreply.github.com) when you interact with GitHub's web UI — editing files, merging PRs, etc.

This helps for web-based actions. It does not help for commits you push from your local machine using your configured git identity. If git config user.email on your machine is your real email, every local commit you push will carry that real email regardless of your GitHub privacy settings.

You can configure your local git to use the GitHub noreply address:

```bash

git config --global user.email "12345678+username@users.noreply.github.com"

```

This is a meaningful improvement, but it ties your entire developer identity to GitHub and the specific username you happen to have there. If you ever change your GitHub username, migrate to another platform, or simply want to maintain a developer identity that is not owned by Microsoft, you need something more durable.

The Identity Separation Framework

The underlying principle here is the same one that applies to AI privacy more broadly: separate identities reduce blast radius. If your developer email is the same as your personal email, a breach or leak in either domain affects both. If they are separate, they stay separate.

The practical implementation for developers:

One identity per role. Maintain a distinct email address for each role that has a meaningfully different risk profile: personal, developer/open source, work, financial. These should not be derivable from each other.

Use aliases, not variations. yourname+dev@gmail.com is not a separate identity — it is the same inbox with a routing tag, and it traces back to the same account. A genuinely separate address at a different domain is what you need.

Choose a provider that respects the separation. Your developer identity email needs to be from a provider that does not sell metadata, does not scan content, and is not trivially tied to your personal account on the same platform.

Apply the identity consistently. Set the git config globally to your developer address, use it as the maintainer email on all packages you publish, and configure it as the contact email for any developer accounts (GitHub, GitLab, npm, PyPI) that are tied to your open source work.

Why Proton Works Well for a Developer Identity

A dedicated developer identity email needs to meet a few specific criteria that most email providers fail on:

  • Zero-knowledge encryption so the provider cannot read your messages
  • Swiss jurisdiction for strong legal privacy protections
  • No metadata harvesting — provider should not profile you based on who you email
  • Custom domain support so your address survives if you ever switch providers
  • Alias support for further compartmentalization within the developer identity

Proton Mail satisfies all of these. The encryption is end-to-end for Proton-to-Proton messages and zero-access for all stored mail. The infrastructure operates under Swiss data protection law (one of the strictest in the world), which means data requests from foreign governments face a much higher legal bar than they would for a US-based provider. And critically, Proton does not scan your email content for advertising or profiling.

For a developer, the practical setup looks like this:

  1. Create a Proton account with a username that is professional but not your real name if you prefer pseudonymity (devhandle@proton.me or a custom domain).
  2. Configure this as your global git email on every machine you develop on.
  3. Use it as the author email on all npm/PyPI packages.
  4. Register your GitHub, GitLab, and other developer accounts with this address.
  5. Set up Proton aliases for specific projects if you want further segmentation (e.g., projectname@yourdomain.com forwarding to your main Proton account).

Your personal email — and everything connected to it — stays entirely separate from your developer work.

A private email built for people who think about threat models

Proton Mail uses end-to-end encryption, stores nothing readable by the provider, and operates under Swiss privacy law. If you're going to have a dedicated developer identity, this is the right foundation for it.

Learn More

Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.

The Setup: Step by Step

1. Create your Proton account.

Go to proton.me and choose a username that works as a permanent developer identity. You do not need to use your real name. Many developers use a handle or a professional pseudonym.

2. Configure git globally.

```bash

git config --global user.name "Your Name or Handle"

git config --global user.email "yourdevaddress@proton.me"

```

Verify with:

```bash

git config --global --list | grep user

```

3. Update existing repositories.

For repositories where you have already committed with your old email, you can update future commits immediately. Past commits remain as-is, but you stop the bleeding going forward.

If you want to rewrite history on a private repository you own (before sharing or making it public):

```bash

git filter-branch --env-filter '

if [ "$GIT_COMMITTER_EMAIL" = "old@email.com" ]; then

export GIT_COMMITTER_EMAIL="new@proton.me"

export GIT_AUTHOR_EMAIL="new@proton.me"

fi

' --tag-name-filter cat -- --branches --tags

```

Only do this on repositories where you control all copies. Force-pushing rewritten history to a shared repo will cause problems for other contributors.

4. Update package manifests.

For npm:

```json

{

"author": {

"name": "Your Name",

"email": "yourdevaddress@proton.me",

"url": "https://yourgithub.com"

}

}

```

For PyPI (setup.cfg or pyproject.toml):

```toml

[metadata]

author_email = yourdevaddress@proton.me

```

5. Update connected accounts.

Change the primary email on GitHub, GitLab, npm, and any other developer platforms to your new Proton address. Enable GitHub's "Keep my email private" option while you're there — it adds a second layer for web-based actions.

6. Consider a custom domain.

Proton supports custom domains on paid plans. If you register a short domain for your developer work (yourhandle.dev, for example), your email becomes you@yourhandle.dev. This address is portable — if you ever switch email providers, the domain comes with you, and none of your public package manifests or git logs need to change.

Proton Pass: Managing the Identities You're Building

As you separate identities across different roles, you accumulate credentials. A password manager that understands identity separation helps significantly.

Proton Pass — included in Proton Unlimited or available as a standalone product — integrates with your Proton account and includes a built-in email alias feature called SimpleLogin (which Proton acquired). From within the password manager, you can generate a new alias address for any service, route it to your Proton inbox, and keep the real address hidden.

For developer accounts at services you're less sure about, this adds another layer: the email you give them is a forwarding alias, not your actual Proton address, so even a breach of that service doesn't expose your real developer identity.

The Proton ecosystem — Mail, Pass, VPN, Drive — is designed around the idea that privacy should be composable. Each product works independently, but they are stronger together. For a developer building out a proper identity separation strategy, having encryption and privacy under one account (rather than stitched together from five different vendors) reduces the attack surface and the operational overhead.

This Is Not Paranoia — It's Hygiene

The developers most likely to dismiss this as overkill are the ones whose emails have already been scraped, indexed, and sold — they just do not know it yet.

Identity separation is standard practice in security engineering. The reason enterprises use separate service accounts, segmented networks, and role-based access control is precisely this: when a breach or leak happens (and eventually it does), containment is everything. The blast radius of a compromised identity is proportional to how many things are tied to it.

Your personal and professional identities are worth separating even if you are not a high-value target. The effort to set it up is a few hours. The alternative is a permanent, immutable record of your real email address embedded in every piece of code you have ever shared with the world.

Start Building Your Newsletter Subscription List

If you found this useful, we publish a weekly breakdown of privacy tools, developer security practices, and practical threat model thinking — no hype, no vendor nonsense. Drop your email below.

No tracking pixels. No third-party analytics. Unsubscribe any time.