OOoooppss...
Ok we don't have time to waste, you did the unthinkable, it was a rookie move, but we need to fix it asap! I'll skip any further banter and cut straight to the case. Here's how were gonna do it...
Quick Summary:
- Remove .env and commit the removal.
- Use filter-branch to delete the file from history.
- Force push the changes.
- Clean up the local repository.
1. Remove the .env File and Commit
- First, remove the .env file from your repository and commit the changes:
bash
Copy code
git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Remove .env file and add to .gitignore"
2. Remove the .env File from History with filter-branch
- Use Git’s filter-branch to remove the .env file from the entire history:
bash
Copy code
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch .env' --prune-empty --tag-name-filter cat -- --all
3. Force Push the Changes
- After running the filter-branch, you'll need to force push the changes to the remote repository:
bash
Copy code
git push --force --all
git push --force --tags
4. Clean Up Local Repository
- Finally, clean up your local repository to remove the old references:
bash
Copy code
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now --aggressive
5. Revoke Any Leaked Credentials
- As with any method, if your .env file contained sensitive information, revoke and regenerate those credentials immediately.
😅 You did it! Hopefully nobody saw that. Pat yourself on the back and please please please don't skip step 5. You need to revoke access and regenerate new credentials to insure that you don't get hacked. You've been warned...
Ok that's it, bye!
Credits:
Author: 👩🏽💻 Kodebae
Buy me a ☕️: (https://www.buymeacoffee.com/karmendurbin)
Website: (https://kodebae.github.io/kodebae-app/)
X: (https://twitter.com/karmen_durbin)
Top comments (23)
It's not worth doing all that though.
Just make sure it's in the gitignore and doesn't get added anymore.
AND go and change all the credentials you accidentally leaked.
And move on. It happens :)
Agreed with @ravavyr .
Point #5 (revoking leaked credentials) should be #1 .
The rest are optional (but recommended) steps.
I would personally still remove the history of the leaked file from GitHub to be safe. ;)
There is nothing wrong with doing that. It's just more effort AND if you don't do it right there will still be some branch/commit/version up there that has your old creds.
This sounds opinion based and isn't the case for everyone. Depending on the level of compliance it is necessary to remove this information from your GitHub history. Its fine if you personally don't want to remove your leaked secrets, but that is simply not an option for everyone.
Everything we do is opinion based, lol.
I don't think it's opinion based. More like under what the circumstances.
If it's public git, github, large team, doing the push force is just cutting your own legs.
If it's private git or small team, then why not properly clean it up and tell everyone to clean their local copy.
@bankde Thanks for this input. I also think that circumstances depending could affect whether or not this is the best way to go about solving the issue. That is a good point to add. But again depending on the circumstances the purge of history may be necessary.
because even on a small team you will end up having this discussion and spend more time arguing about it than just updating your creds and gitignore and moving on.
@ravavyr I heard your opinion on the matter and I disagreed. I linked a few resources already, one from github themselves and some from other people where they all suggest a similar process to what I did. If you don't want to follow the steps I understand.
Enjoy the rest of your day.
Please elaborate, why do you think that removing the history from the GitHub branch is not useful?
because it's more effort than it's worth?
Even if you do that, you still need to clean up your credentials because they have been leaked.
So just clean up your credentials and move on.
Great Article , If you dont mind me asking , where should i store my .env information other than github as a backup do you have a tool in mind or similar that organizes your .env files ? because from my end i just keep the .env file and make the repo private , And thank you in advance for your time for reading my question.
I agree with @brian_rlist_c3025e6dbb I found the simplest solution is to store the file in a Keypass database and use a backup tool to backup the database and if you want to get fancy use the keypass cli to export it before build and deploy but thats optional
You may want to keep the sensitive credentials (oAuth tokens, etc.) in a password manager or similarly secure place, rather than any typical backup method
I like to create a
SAMPLE.envfile that contains all of the non-sensitive variables, along with comments about each variable, and a just a placeholder for any oAuth tokens or other credentials. I let this file make it into the repo by design. (Don't put*.envin the.gitignore, just.envas described in the article above to ensureSAMPLE.envis not ignored).This gives me a backup of the entire file (minus the secrets) right in the repo, and serves as a template/quick-start for other users of the code.
Whether you are recovering from a drive loss, setting up on another computer, or another developer is using your code, you simply
copy SAMPLE.env .envand update the placeholdes with the credentials.vaultproject.io/
github.com/AGWA/git-crypt
🥴 Just going to link over to this blog post now.
I know that there is some debate going on in the comment section right now about how "unimportant" it is to remove history or rewrite the GitHub history after credentials are leaked. Yes, this is an optional thing no one is forcing you to do this. It's not something that anyone is "required" to do, but I have looked into this and having this information floating around out there can have its drawbacks. All debatable yes, so do your own research and decide for yourself.
Linking yet another resource with a quote here for those who are not 100% convinced on removing leaked secrets.
What to do after leaking credentials and API keys
"Once the secret has been revoked, it cannot be used anymore. Nonetheless, having credentials, even expired ones, could look unprofessional and raise concerns. Additionally, some secrets cannot be revoked (for example, database records), or credentials no one can guarantee were properly revoked (for example, SSH keys that can be used in many different places). While we will go through the steps of how to remove secrets from the git history, please note that this is not a trivial task, and it is advised to seek the guidance of a senior developer."
I agree with others, that removing the leaked file from GitHub is a safe move.
If you're planning to put tokens which can be regenerated, removing the .env file entirely from the git history is worthless. Just regenerating the credentials and adding the file to the ignored list should work wonders.
Thanks for the comment. I linked a few resources that detail when removing the history may be necessary. This is not a one size fits all situation.
👋🏽 Hey everyone, thanks for the comments!
I'm just now checking up on the comments here, it's been a long week.
Thank you all so much for your kind words about the article! 😄
For storing .env files securely, there are a few different options for encryption tools like EncFS for local backups or services like HashiCorp Vault for more advanced secret management. If you're looking for organization, using environment-specific .env files (like .env.development) combined with a tool like direnv could be very beneficial.
Remember to try and never commit these files to GitHub, even in private repos, and use .gitignore to exclude them. Hope this helps!
Well, you can't delete data from Github, because Git is snapshot based VCS trufflesecurity.com/blog/anyone-ca...
Yes GitHub is indeed snapshot based but that is why we are pruning the history in step two to rewrite the commit history. That is the entire point of this blog post. You can find more information here in the official documentation.
Removing Sensitive Data from GitHub