0

I accidentally managed to commit a file that contains passwords, and push the result into GitLab. The project is private, and the passwords aren't actually important, but I want to remove all trace of them from GitLab, and from my local repo, though I need the files to continue to exist on the local filesystem.

So far, I did a git `rm --cached ' but I'm not sure if that really removed all trace of the file in the repo, and it has the side effect that now I can't do a push with the error "Updates were rejected because the remote contains work that you do not have locally."

I guess I could perhaps just destroy the GitLab repo, rebuild it and re-push, but a) I'd like to be sure that the git rm I mentioned above will have done what I want, and b) it seems there might be an easier route?

I've found lots of answers that dance around various permutations of these elements (though nothing specific to GitLab). Frankly, however, they're all just different enough that I'd prefer an answer that's specific to this particular set of constraints.

halfer
  • 19,824
  • 17
  • 99
  • 186
Toby Eggitt
  • 1,806
  • 19
  • 24
  • 2
    There's a Git part, which is a duplicate, and a GitLab part, which might not be. For the Git part, see [here](https://stackoverflow.com/q/16877530/1256452), [here](https://stackoverflow.com/q/3458685/1256452), [here](https://stackoverflow.com/q/43762338/1256452), and many others. – torek May 02 '22 at 03:18
  • 2
    The fundamental issue here is that Git is built to *add* commits, and never to *remove* them. So removing a commit is difficult (and if it's not the *last* commit in a branch, involves "rewriting history": basically making a *new* repository to use *instead of* the old one). Moreover, Git is "greedy" for new commits: connecting two Gits together, one of them hands over the commits the other doesn't have yet. This causes commits to spread like viruses. It can be almost impossible to stamp them out. – torek May 02 '22 at 03:21
  • 2
    Last, GitLab might not remove a commit even under the rare conditions that occur where Git itself removes commits. (This is true for GitHub for instance, because of the way they implement GitHub forks.) So even once you've stamped out the commit from all the repositories you control directly, you need the host admins to do that for the hosted repositories. The precise method *for* that depends on the host. – torek May 02 '22 at 03:22
  • So... @torek you're saying that at the absolute minimum, I must destroy the gitlab repo, and almost certainly will have to destroy the local repo and simply do without my revision history? – Toby Eggitt May 02 '22 at 03:23
  • 2
    It depends on what the GitLab administrators can do. You can use the linked questions to fully purge the commit from your own local repository (the easiest way is to use the newfangled `git filter-repo`, which literally makes a replacement repository you can just install over top of the old one: just remove the old repo and put the new one in place and you're good to go). I don't use GitLab and cannot answer the other half. – torek May 02 '22 at 03:29
  • 2
    Just remember that anyone who's had access *to* your local repository may, by this point, have copied the commit you didn't want them to copy. You cannot get them to give up their copy of that commit, so consider the passwords compromised. – torek May 02 '22 at 03:31
  • At this point, it's a private repo and I'm the only one with access. I'll delete it and follow the other links for the local copy. Thanks. – Toby Eggitt May 02 '22 at 03:35

1 Answers1

0

For sensitive data, you need to install the new git filter-repo, which will replace the old git filter-branch or BFG.

The goal is to fix the commit history locally, before pushing to (gitlab/github/...)

Example:

To replace the text 'password' with 'p455w0rd':

git filter-repo --replace-text <(echo "password==>p455w0rd")

Note it creates a new commits history, not just for your current branch, but for all branches (where your password was found)
That means a git push --all --force, to override the history of the remote repository.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250