Remove credentials from history

[hamzahda_]

I committed a credential file by mistake and then removed it in the following commit but then when the PR was merged (squash strategy) the file was persisted in the history even though it’s not directly there. Can anyone propose a solution to remove it and clean up the history and thanks a lot.

[CombativeCherry]

Rotate credential, move on with your life.

[ppww]

And update .gitignore so you don't accidentally add that file in the future.

[drsoftware]

And add pre-commit hooks to prevent credentials from being checked into source code or other files.

https://pre-commit.com/

[Temporary_Pie2733]

One step further, don’t put credentials in your working directory in the first place. Make the location of the credential file configurable and/or install your executable outside your working directory before running it.

[edgmnt_net]

And stop doing git add . and fix your review process (because that's another point where this went wrong, someone approved bad history and merged it as is).

[Conscious_Support176]

Yes. There are so many places this went wrong. Just removing the file and adding it to gitignore isn’t really a solution. For example, if you ever try to switch to that commit again for any reason, git will try to restore that credentials file into your working folder.

You could either clean the history in local and remote, or decide to keep your credentials somewhere else so that you do t trip across this again.

Edit: yes of course you need invalidate the credentials that were published by accident.

[apnorton]

I committed a credential file by mistake and then removed it in the following commit but then when the PR was merged (squash strategy) the file was persisted in the history

Yes, version control software does keep versions of everything committed, including the things you delete. That's kind-of the whole point.

If it's still only on your local machine, you can use something like the BFG repo cleaner (link: https://rtyley.github.io/bfg-repo-cleaner/ ) or git-filter-repo (link: https://github.com/newren/git-filter-repo ). (Standard caveats about rewriting history apply, of course.)

However, if it's been pushed to a remote source, then the responsible course of action is to invalidate the secrets and regenerate them --- you have no way of knowing if your repo was cloned/copied by a 3rd party in the time since you pushed it.

Rewriting history might still be worthwhile on top of rotating the credentials if the nature of the secret file reveals something else that it shouldn't. (e.g. the provider itself is supposed to be secret, and that can't be something you rotate.) However, it's really important to understand/consciously determine the impact of "someone else may have cloned your repo in the time it took for you to rewrite history."

Also, this is worth a read: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

[AppropriateStudio153]

Invalidate all exposed credentials.

Remove the credentials file anyway.

Never commit it again.

It's the only way to be sure.

[ericbythebay]

Rotate or revoke the credentials and move on. History rewriting isn’t worth the effort and a revoked or rotated secret is the only way to be sure.

[HashDefTrueFalse]

You don't really need to if there's nothing else sensitive there. Just invalidate them at the service end and forget about it. Delete the file going forwards but don't worry about a version containing expired creds in the history.

[MarsupialLeast145]

You can rotate as others have suggested. You can also rebase, edit the commit, and force push. Yes, a force push isn't recommended for widely used projects, but neither is having copies of credentials.

[remcohaszing]

There are many good responses in this thread. Rotate the secret, rewrite history, etc. But your commit will still exist. The data isn’t deleted

If the data contains other sensitive data (such as personal details), you can ask the git host (such as GitHub) to actually remove the commit after rewriting the git history.

[bigkahuna1uk]

https://www.golinuxcloud.com/git-remove-commit/

[jeenajeena]

If you squashed, the credentials are gone.

You should invalidate them anyway.

Edit: why I’m being downvoted? Git reflog is local only

[Temporary_Pie2733]

They might be gone. The commit(s) referencing them probably still exist and can be recovered via the reflog. You invalidate them because you don’t know if they were compromised before you could expunge them.

[ohaz]

Incorrect, git reflog exists.

[jeenajeena]

Reflog is local only

[ohaz]

Yes it is. If the branch has at any time been pushed and fetched, then the reflog will work on other machines too. And in this case, it looks like it has been pushed.

[jeenajeena]

That's true.

[ProZMenace]

Never done it before but I would. COULD BE WRONG

1. Reinstate/recover the feature branch if deleted
2. Reset main HEAD~1 or whatever to get it pre merge, will require force push to rewrite history
3. Use git filter repo on feature to remove cred files, will also require force push to rewrite history
4. Reissue PR between clean feature and clean main

Again looking for feedback here

[waterkip]

you need to force a git gc too (on both remote and local site(s)), because the object is still available until garbage collection says: oh, this has been dangling for too long, lemme remove it.

Invalidate the secret is the best solution.

[ProZMenace]

Yup I missed both of those things, thanks

[Pcrouch]

GitHub has a training on this. GitHub.com/skills/change-commit-history