[ADDITION] AnonGit

[radioactively]

Category

Metadata removal

Software to be added

AnonGit is a script to anonymize git commit authorship and timestamp.

Contributors of privacy-related open-source projects may want use the script to avoid leak information from their timestamps (timezone leaks location, time of day leaks routine schedule, week days and month may be linked to religion practices, holidays, and festivals), and depending on the project go further and anonymize authorship (extreme scenarios like Samourai wallet or Monero, whose devs were targeted by providing privacy tools)

The script can:

• Anonymize entire git history
• Anonymize single commit
• Anonymize multiple commits
• Anonymize commits filtered by author/committer, date range, or commit message
• Anonymize metadata using arbitrary values for user name, user email and date
• Anonymize just the timestamps (keep authorship) or the username (keep timestamp)
• Anonymize the timestamps partially: preserve commit year or month or day while anonymizing other information (hour & timezone)

Each contributor/developer can use the script independently of the others. A developer may download the script, use it for his own commits before opening a PR, then open his PR without affecting devs who don't want use it.

Supporting Material

https://github.com/radioactively/anon-git

The script itself provides all instructions via --help option and the README has more comprehensive information such as usage examples and security notes.

Affiliation Disclosure

Author

Would you like to submit a PR?

Yes!

Please tick the boxes

• You have filled out this form accurately, and to the best of your knowledge
• You have indicated whether or not you are associated with the suggested addition
• A similar submission has not already been opened for this software / service
• You agree to the code of conduct

[lissy93]

My first thought when I read this, was "how's a script from 2008 using git filter-repo which was only released a few years ago" 😂 It's funny how much trust we subconsciously put into git logs, despite how easy they are to re-write.

It's a neat script @radioactively - nice work :)

I'll need to create a new section under Development if this were to be added, since there's not yet an appropriate place for it.

---

Just a few thoughts, not postivie/negative just me thinking outloud..

I guess it would be worth noting, that if you tried to use it when collaborating or on a larger or shared git repo, it is probably going to break things (becasue of the destructuve history re-writing). But the branch backup feature is a nice touch.

Generally speaking, the correct operational model is not "rewrite later", but set the right identity before committing.

E.g. Setting a per-project .git/config and/or an alias with the pre-set git env vars. And yes, this would only be applicable to new commits, but it's much cleaner, less risky and better practice.
This would also allow for GPG-signed commits with your pseudonym's key, (since anon-git currently strips this), and some projects enforce signing as a requirement (like OpenBao).

And just a discussion point in your readme, where you say: "Many privacy & freedom-oriented projects prefer (or even require) contributors to avoid leaking personal metadata"

Yes and no. True that you never want to expose contributor's identities, nor for any personal info to be leaked. BUT re-writing history destroys provenance, since (without the hashes, timestamps and signatures) you break the audit trail. It makes it hard to verify who/what/where/why/when a change was introduced or if it was tampered with. And in security-foduced packages that'd underminie traceability, reproducibility, and trust in the codebase.

Another thing you might want to think about, is operational safety. Right now, there's no strong guardrail against running this somewhere unintended (like on a branch with an upstream remote, a dirty working tree, a repo with ongoing rebases/merges, a detached HEAD state or the wrong repository entirely). That is the sort of thing that turns a niche lil tool into a footgun.
Adding a bit of idiot-proofing like checks or confirmations would be nice.

[radioactively]

My first thought when I read this, was "how's a script from 2008 using git filter-repo which was only released a few years ago" 😂 It's funny how much trust we subconsciously put into git logs, despite how easy they are to re-write.

That is the point of the script hahaha. I've used the script upon its repository.

Generally speaking, the correct operational model is not "rewrite later", but set the right identity before committing.

Yes, agree. I added some instructions to add the script as git hook triggered after every commit. A standalone developer can use the script as a hook, without commiting the hook to the repo and without affecting the other devs.

E.g. Setting a per-project .git/config and/or an alias with the pre-set git env vars. And yes, this would only be applicable to new commits, but it's much cleaner, less risky and better practice. This would also allow for GPG-signed commits with your pseudonym's key, (since anon-git currently strips this), and some projects enforce signing as a requirement (like OpenBao).

I'm not familiar with this git env vars. Through these git env vars or via .git/config, how could we improve the script to allow GPG-singed commits?

re-writing history destroys provenance, since (without the hashes, timestamps and signatures) you break the audit trail. It makes it hard to verify who/what/where/why/when a change was introduced or if it was tampered with.

Sure, I'm aware of that. The script just facilitates what can already be accomplished with git filter-repo and its usage is completely up to the developers of any repository. That is why the script by default only anonymizes the latest commit; it asks for confirmation and it creates a backup branch. Even if everything is messed up, the original commit history can be recovered (git keeps unreferenced objects for like 1 to 2 months).

And in security-foduced packages that'd underminie traceability, reproducibility, and trust in the codebase.

For sure, it would be devastating rewriting history of projects in such scenarios, specially libraries, packages and plugins that are audited, published and distributed. I do not expect the script to be used to rewrite old history by big repositories, with couple to dozens of contributors, and with a long timeline. I expect it to be used for new commits or for projects with few contributors that can agree upon rewriting their history.

Another thing you might want to think about, is operational safety. Right now, there's no strong guardrail against running this somewhere unintended (like on a branch with an upstream remote, a dirty working tree, a repo with ongoing rebases/merges, a detached HEAD state or the wrong repository entirely). That is the sort of thing that turns a niche lil tool into a footgun. Adding a bit of idiot-proofing like checks or confirmations would be nice.

Sure. I'll add some checks to double check remotes. My first thought was, instead of rewriting for the current branch, create a new branch on top of it <current_branch>-anonymized-<date> and then rewrite the new branch, leaving the rest intact. Do you have any other suggestion?

[radioactively]

Just another comment.

BUT re-writing history destroys provenance, since (without the hashes, timestamps and signatures) you break the audit trail. It makes it hard to verify who/what/where/why/when a change was introduced or if it was tampered with.

You may have missed the options for partial anonymization:

• --keep-user will keep authorship; anonymize only timestamps
• --keep-date will keep timestamps; anonymize only the author
• --keep-year will keep commit year; anonymize month, day, hour and tz
• --keep-month will keep commit year and month; anonymize day, hour and tz
• --keep-day will keep commit year and month and day; anonymize hour and tz

The options --keep-day may suit best for "large" projects because it keeps git contributions statistics while anonymizing the time of day and the tz(time of day may be reveal information about work and routine schedules, and timezone may be linked to location). keep-month goes further and anonymizes the day of the commit, and those days can be linked to cultural/religion practices (such as work days, worship days, etc), festivals, holidays...

Thus, I do believe it is possible to preserve the audit trial with partial anonymization, allowing spotting who introduced a bug (--keep-user) and when (--keep-day).

[arnon-shub]

A few thoughts after reading through the README and discussion:

The partial anonymization flags (--keep-day, --keep-user, etc.) are genuinely well thought out. That part is good.

But there's a point from @lissy93 that hasn't been fully addressed: if the repo is already on GitHub and someone has cloned it, rewriting history doesn't help. The metadata already leaked. The tool doesn't make this clear enough — it should probably warn upfront that history rewriting is only meaningful before a public push, or in repos with no external clones.

The guardrails issue also stands. Creating a new branch (<current_branch>-anonymized-<date>) is a reasonable approach, but it hasn't been implemented yet. Until it is, running this on the wrong repo or wrong branch is a real risk.

The bigger concern nobody's raised: the tool assumes the threat model is "I want to hide who I am" — but if you're using GitHub, GitLab, or any hosted forge, they already know who you are regardless of what's in the commit metadata. This tool is most relevant for self-hosted git or anonymous remotes, and that should be front and center in the README rather than buried in the security notes.

The git hook approach is the most practical use case here. For new commits on personal branches, it's clean and low-risk. That's probably where most real-world usage will land.

[radioactively]

But there's a point from @lissy93 that hasn't been fully addressed: if the repo is already on GitHub and someone has cloned it, rewriting history doesn't help. The metadata already leaked. The tool doesn't make this clear enough — it should probably warn upfront that history rewriting is only meaningful before a public push, or in repos with no external clones.

I added a note about that under important notes sections on readme.

The guardrails issue also stands. Creating a new branch (<current_branch>-anonymized-) is a reasonable approach, but it hasn't been implemented yet. Until it is, running this on the wrong repo or wrong branch is a real risk.

The default behavior is to create a new branch instead of rewriting the current one. The flag --current-branch is needed now to overwrite the current branch.

if you're using GitHub, GitLab, or any hosted forge, they already know who you are regardless of what's in the commit metadata.

This is not true at all, because even when using anonymous accounts (anonymous nickname and throwaway email) you may still leak a lot of information about yourself:

• timezone may be linked to location
• time of commit may be linked to work and routine schedules
• day of the week may be linked workdays and religious/cultural practices (rest days)
• day and month may be linked to holidays, festivals and cultural/religious events
• cadence between commits may leak information about commit frequency and coding pace, revealing personal development patterns (some developers commit frequently, while others code more before committing)

---

Do you have any other improvement suggestions? I'll address it.

[lissy93]

I'll add a new section "Dev Utils" (in #458)
There's probably a bunch of useful things which could be included there too!

---

Lol at Satoshi Nakamoto busy contributing to AnonGIT 😂😂
But for real, how'd you get a contributor to show up without them being associated with a commit? I've not seen that before.

[lissy93]

I'm not familiar with this git env vars. Through these git env vars or via .git/config, how could we improve the script to allow GPG-singed commits?

Yeah, it's a different approach.
So, as well as your global user git config (in ~/.gitconfig) you can also create per-project configs in .git/config (or even one just for your current working tree, in .git/worktrees/<name>/config.worktree).

So, you could add something like this into any of those gitconfigs:

[user]
  name = nightjar
  email = nightjar@users.noreply.codeberg.org
  signingkey = ABCD1234EF567890

[alias]
  canon = "!GIT_AUTHOR_DATE='2008-10-31 00:00:00 +0000' GIT_COMMITTER_DATE=\"$GIT_AUTHOR_DATE\" git commit"

Then, when you go to commit, you'd run:

git canon -m "my super cool commit"

Now you'd have both an anon git author, GPG signature, and custom commiter and author dates.
But again, that's just for current commits, no re-writting (which personally, I prefer - but it's a different use case)

Btw, .gitconfigs can go deep! If you're interested, there's loads of things you can configure there which can also help with privacy and security. Here's some i can think of:

user.useConfigOnly = true       # Stops Git falling back to your system username/hostname
tag.gpgSign = true              # Because signing tags matters more than commits
push.default = simple           # Safer push behavior
push.autoSetupRemote = false    # Helps avoid accidentally creating/upstreaming a new branch
push.followTags = false         # Stops implicit tag pushing
pull.ff = only                  # Prevents surprise merge commits
fetch.prune = true              # Just keeps local refs tidy :)

[gitgost-anonymous]

Hello everyone,

For those looking to contribute to repositories without leaving traces in Git metadata, I wanted to mention gitGost as a practical alternative to the commit anonymization flow. The system operates in total privacy because users do not need to create accounts. The system provides two main features which allow users to operate anonymously through PRs together with their updates. The system enables users to receive PR notification through ntfy.sh without needing to use email.

Users can work on public repositories while using Tor to protect their IP address. The system functions to protect user privacy because it requires no account setup and provides simple operation.

The official website and testing page can be accessed through these links.
The official website exists at this URL https://gitgost.leapcell.app/.
The GitHub page can be found at this URL https://github.com/livrasand/gitGost.

I believe gitGost serves as an effective tool which supports extreme privacy cases together with AnonGit when users need to make anonymous contributions and prevent metadata leaks from their public repositories.

---

goster-2e6be6c2 · karma (1) · report

[gitgost-anonymous]

Oh, this is cool!! 😎

---

goster-930cf07e · karma (1) · report

[gitgost-anonymous]

Oh, this is cool!! 😎

---

goster-844048b7 · karma (1) · report

[arnon-shub]

@radioactively You're right about the metadata leakage point — I was thinking about identity in the narrow sense and missed the behavioral angle (timezone, commit cadence, day-of-week patterns). Fair correction.

The new-branch default and the README additions address my earlier concerns. Nice work.

Minor idea: a --dry-run mode that previews changes without rewriting could lower the barrier for new users and reduce risk of accidental runs.

[radioactively]

Lol at Satoshi Nakamoto busy contributing to AnonGIT 😂😂 But for real, how'd you get a contributor to show up without them being associated with a commit? I've not seen that before.

If you publish a repository on GitHub, then any commit whose email belongs to a GitHub user (with email verified), then GitHub will show that user as a contributor.

For example, If I create a local repository using your public email @lissy93 , then publish it on my account, GitHub will show you as contributor even though you may have nothing to do with it. That is why it is important to have GPG-signed commits otherwise someone can claim you contribute to nasty projects you didn't.

When I first created the script, I place the default author to be Satoshi Nakamoto <satoshi@gmx.com>, which was Satoshi's email when he was active. When I push my repo to GitHub, the commits were authored by satoshi@gmx.com. Since Satoshi has disappeared, someone else has got access to his email account -- (what I guess has happened is that his email account was inactive, then it was automatically deleted, then somebody took the opportunity to create a new account using his old email address). It seems the username @thisdick69 has verified he/she owns the satoshi@gmx.com email. Thus, when I first published anon-git the GitHub associated the commits with this user, despite he/she has nothing to do with it. I changed the default AnonGit user to be Anon <anon@localhost> but it seems the remote AnonGit hosted on GitHub still has un-referenced commits with <satoshi@gmx.com> email.

This has lead me to realize:

• GPG-signed commits are important
• We need to be careful with the email we use in git history -- if the email domain belongs to a company and you lose the email, someone else will get access to it
• Some jerk took Satoshi email and created a github account with nickname thisdick69