I'm sure this happens to everyone sometimes. You accidentally pushed a file with secrets or a password that shouldn't have gotten into the Git history.
In the following example, I "accidentally" pushed my .env file to Git simply because I forgot to add it to me .gitignore file.
Note: If you accidentally pushed secret keys to a repo, you should always revoke them and generate fresh keys!
Removing the file right away
The best thing to do now is to remove the file right away and add it to your .gitignore file.
In my case, I added the following to the .gitignore.
# Secret file
.env
Let's try and push that to see what happens.
Yep, the .gitignore file doesn't untracked already committed changes. So how can we fix this now?
Removing a file from Git only
You can remove a file from Git by running the following command.
git rm -r --cached .env
If we then push this change, you will see that the file is gone in GitHub.
However, this didn't completely solve our issue. If we look at our Git history, we can still find the file and expose the secrets!
Completely remove a file from Git history
To remove the file altogether, we can use the following command.
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch .env" HEAD
You will get some warnings about this messing up your history as this goes through your whole history and 100% removes its occurrence.
To push this, you have to run the following command.
git push --force
If we look at our history, we can still see the commits that include this .env file, but the content is empty.
Few, thanks for having our back Git!
You can find the repo it tried this in on GitHub.
Thank you for reading, and let's connect!
Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter
Top comments (20)
This is the most succinct and direct guide I've ever read on this issue!. Thank you so much! I have to save this now for future reference.
Glad it helped π
Thanks Chris! This saves me from future troubles.
Good article - you should add a paragraph about needing to rotate the secrets that were checked since they have now been publicly exposed (albeit briefly)
I've added a small note for that :)
Forgot it in the initial draft.
I tried this on my repository, got the same result on GitHub.
However, I found a small gotcha. If you put the file name in commit message like 'Add .env' and you do
git log --all --grep='.env', then you get 2 commits pointing to it. One is the old commit and the other one is the new rewritten commit.And if you copy the old commit id and search it in GitHub, then you will be able to see the content of the file.
Even if you don't put the name of the file in the commit msg, there's still a possibility of an attacker going through all the commits and finding the .env file.
Wow, nice catch Drishit!
Didn't think that far ahead to be honest!
So well done on exposing this, def worth while fixing that as well.
I guess, we should take into account the affected commits will change their SHA it will cause conflicts with already cloned repositories, doesnβt it?
Good question actually!
Not to sure how it behaves on cloned repo's.
Oh this will mess up the history of the repo real good and anybody who tries to pull force-pushed commits will get errors. But if anyone is pushing secrets to a central branch that a team is pulling from, that team has bigger problems anyway.
The solution that I have in picture is just notify the team to wait for the fix then do the βpull βforceβ, because as you said itβs an important security fix then all will be sync and can work.
Unfortunately things like this (maybe not a .env file) but a hardcoded secret perhaps? might ever be committed and even pass a PR.
Mistakes are human, and agree once this happens you should notify the team and work on getting this sorted right away and make sure everyone is up to date in source again.
brew install bfgAs long as a repo is private or local, a .env file could be commit into the repo.
I would also urge to not do that.
What happens when you decide to introduce someone else, sell the project or code gets leaked?
Perfect, I've been looking for this my entire life. π
Glad it helps Mohmed! π
Nice article as usual Chris! π
Have you thought about linking all the Git articles into a series? I think that would be helpful for someone who lands on them in the future.
Good point Abhinav.
Always forget to do that as it's automatic on my blog!
Doing it right now! π
done this but the file is still there, if I look at the initial commit and at the commit I made to remove the file (last year).