Some weeks ago I accidentally committed a configuration file containing some passwords and I pushed it on a GitLab remote managed by my company.

After that I used BFG Repo-Cleaner to remove the passwords from the history.

After the clean I executed:

git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

I seen the commit hashes have been changed and sensitive data has been removed (I can see that both using the GitLab web interface or exploring a new clone of the repo).

However, if I access one of the old pages calling directly the URL (https://<my-company>/gitlab/test-bfg/commit/<theoretically-unexisting-hash>) I can see a gitdiff of a commit containing the passwords! I discovered this accidentally, navigating on the browser history.

If I try to checkout the same hash on the just cloned repo I obtain this message:

fatal: reference is not a tree: d7fb999c...

So, if a person clone that repo from GitLab I think he or she is not able to view that commit*, however it is still visible from the web interface, if one could guess an old hash.
* Anyway, I I would feel more comfortable reading did not match any file(s) known to git instead of reference is not a tree.

I don't think this is a kind of cache problem, because I tried it again after some hours.

So, questions are:

  • Why this happens? Am I using the tools in the wrong way?
  • There are some ways to see that hidden hashes?
  • Did you ever experienced this, maybe using different systems (GitHub, BitBucket)?

Thank you very much.

closed as off-topic by Teun Vink, TheJulyPlot, Xander, Tobi Nary, Steve Sep 8 '17 at 14:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Teun Vink, Steve
If this question can be reworded to fit the rules in the help center, please edit the question.


git gc only affects your local copy and the following git push will not propagate any instruction for garbage collection to the remote site. See also How can I trigger garbage collection on a Git remote repository? and Removing sensitive data from a repository (at github). And while the last one helps you with removing some sensitive data it also contains a clear warning of the limitations of this approach:

Warning: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised.
... commits may still be accessible in any clones or forks of your repository, directly via their SHA-1 hashes in cached views on GitHub, and through any pull requests that reference them. You can't do anything about existing clones or forks of your repository, but you can permanently remove all of your repository's cached views and pull requests on GitHub by contacting GitHub Support.

And while this is from Github it is probably similar on Gitlab.

  • I think it could be the same cached views issue you pointed out. I asked also in GitLab forum. I'll update my question if they will answer me. – xonya Sep 8 '17 at 12:39

I'm not very familiar with Gitlab or what BFG repo cleaner does. But it is always a good idea to rotate your passwords when they have been exposed in public. If it's a public repository, there's no way to reliably know if the old git commits have been checked out by someone. That said, lodge a support request with GitLab too, just in case.

  • 1
    Yes, these is a good advice. However the repo is currently private and I wanted to remove the passwords just because we decided to make it public soon. I hoped simply rewriting the history could be enough. Anyway, I asked also in GitLab forum. I'll update my question if they will answer me. – xonya Sep 8 '17 at 12:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.