Stripping sensitive info from Github.
Ever have auth keys and other sensitive info accidentally pushed to a public projects repo? It happens, and when it does you should move swiftly to correct it as keys and their related accounts may be compromised. If left uncorrected, this may mean a big fat bill at the key owner's expense, or a disruption in your apps functionlity due to unauthorized excessive requests. Here is a step by step run down on how to erase all commits associated to files with sensitive data.
Note: Before continuing through the steps below, it is adviseable to save a copy of the compromised repo on your local machine in case of issues with stripping. Make sure to give it a discreet name like Old_app_name to distiguish this version from the future stripped app.
Now we can proceed: 1. Identify which files contain auth keys and the sensitive data to be corrected.
2. In the app's root directory run this multiline command:
git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch your_file's_path.here' \ --prune-empty --tag-name-filter cat -- --all Note: Change "your_file's_path.here" to the actual path to the file to be stripped. It's important to make sure the commands are entered in multiple lines exactly as shown, otherwise it will produce an error.
3. Add the corresponding file to the .gitignore directory to protect it from being accidentally pushed.
echo "your_file's_path.here" >> .gitignore
4. Then, add and commit the .gitignore directory.
git add .gitignore git commit -m "Add file_you_are_stripping to .gitignore"
5. Repeat steps 2 through 4 for each file containing sensitive data.
6. Once that is done and you are certain all corresponding data has been removed, over-write the repo with git push origin --force --all
7. Finalize the process with
git push origin --force --tags
At this point, the repo on Github should be free of sensitive info and is ready to share. Your keys and sensitive data will now exist locally and can be referenced via ENV variables by the rest of your app.
Since stripping is specific to the repo these commands have been applied to, it does not affect any project forks before then. Hypothetically speaking, the means that if Mary of Joe forked the project before the sensitive data was stripped, Mary's and Joe's forks still have my keys on it. Also, even if the project has never been forked, you can consider keys compromised just for having been made publically available. For this reason, and to be safe, it is advised that one requests new keys from their corresponding issuer to protect accounts.
In my case, I have opted for creating a new stripped repo for our project. I asked collaborators to delete old forks/repos from Github and for the project once they've tested my new stripped repo to work. Everyone will also get a their own keys to work with.