1

I accidentally committed a password to a feature branch and synced that branch to remote. I tried to clean the branch commit history with bfg without success and with git-filter-repo I'm having other problems.

I now committed the settings file without the password to the branch.

If I merge the feature branch to the source branch with squash merge and delete the feature branch, will that effectively remove the password from all git history?

Mathias Rönnlund
  • 4,078
  • 7
  • 43
  • 96
  • 2
    squash merge would only keep the last commit in the visible history, you could also remove the file with `git rebase -i`. Not sure how git handles this on the server, but it will probably take some time until your password-commit is garbage collected and you should consider the password compromised anyways. – ian Nov 10 '20 at 20:10
  • Squash merge and branch delete will remove the commits from the repo history (and probably eventually purge the orphaned commits), but if you're using server side tooling to do this within a Pull/Merge Request, the commit history of that request may be retained. See my answer for a simpler approach. – TTT Nov 10 '20 at 20:26
  • @ian agreed. I think interactive rebase is the way to go here. – TTT Nov 10 '20 at 20:29
  • Is this a public repo, or private within your organization? Can everyone who has access to the repo be trusted? – TTT Nov 11 '20 at 04:58

3 Answers3

1

What I finally did was

  • to revoke the password in the target system
  • remove the password from code with a new commit
  • adding in the comment that the earlier seen password had been changed

Best to not be lazy with your mistakes but take the steps to change the password.

Mathias Rönnlund
  • 4,078
  • 7
  • 43
  • 96
0

It sounds like so far the password is only on your local feature branch and on the remote feature branch. The easiest way to remove it is to get rid of it locally and then force push it back out. Use amend or interactive rebase to rewrite the commit locally without the password, and then force push out your branch. At this point the commit will remain hidden on the server until it is garbage collected, and the amount of time that takes depends on the server. (Some git clients default to 60 days but it's impossible to know what your server defaults to without more info.)

Note if you already created a Pull/Merge Request with the branch that contained the commit with the password, then the server may keep the history of the included commits indefinitely. For this reason I would avoid squash merge at Pull/Merge Request time because it may keep the history of the commits for a long time.

If your repository is public, then you should assume that the password has already been compromised and you should change it immediately. In fact, this is probably the safest option even in a private repo too, unless you're fine with it being shared with your collaborators.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • I would love for someone to explain the DV here. I'm guessing because my third paragraph wasn't first? – TTT Nov 11 '20 at 04:56
0

First let's cut to the chase:

That password has been compromised. There is no way for you to trace where it might have gone after you pushed it to the remote. You can't put that genie back in the bottle; the only secure thing to do is to change the password.

That makes the rest of the discussion mostly academic. Either the password won't be changed and removing it from the history is an insufficient measure, or it will be changed and removing it from the history is cosmetic.

Nonetheless, to answer your direct question:

If I merge the feature branch to the source branch with squash merge and delete the feature branch, will that effectively remove the password from all git history?

Not really. To fully remove the data from your local repo, you would have to make sure that the commit(s) containing it are unreachable from all refs as well as the reflog, and then you would have to force garbage collection. To truly remove it from the remote requires similar procedures, but how that sort of housekeeping is handled varies depending on how the repo is hosted.

And again, all of this would assume that nobody had already fetched a ref whose history contains the password. If they did, nothing you can do will force them to discard it.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • Wouldn't reflog most likely only be on the user's machine? (Unless it's a public repo, then who knows...) I'm acting under the assumption the user's machine is secure. – TTT Nov 11 '20 at 04:54
  • Someone also DV'd this answer? This answer seems perfectly reasonable to me, as does my answer. Someone needs to provide some clarity here. – TTT Nov 17 '20 at 22:57