This appears to be the recommended method for removing sensitive data in git history. These steps don't appear to work in the GitLab web interface. Also note that my local git copy properly purges the sensitive data.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Hi Jason. If you rewrite history and force push then it should work. GitLab just shows whatever history is actually available in the bare git repo. The only thing that could stop this is if the master branch is protected. You may need to temporarily unprotect it when you force push the new history.
I tried your suggestion. It does properly remove it in git history however not from gitlab entirely.
I can still see the commit if I load it directly from the commit hash by visiting gitlab.com//<project_name>/commit/<commit_hash>
That link is referenced in
Click Merge Requests >> Merged (tab) >> Title of merge >> Commits (tab)
However, I believe GitHub has updated it's help site on this subject and it now contains the following message:
"This article tells you how to make commits with sensitive data unreachable from any branches or tags in your GitHub repository. However, it's important to note that those 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."
And I agree. It's a lost cause. Just consider the sensitive information compromised and deal with it by changing a password or updating your private keys, etc
@jheithof The reason may be that the repository needs a git gc --prune run on it. Even if no branch references that commit it may still be present in the repo until it is pruned. Prune only removes objects older than 2 weeks, so consider that, too.
But yes, your tip to assume it's been compromised and just change your secret is a great approach. Even if you successfully get rid of the commit it could have already been skimmed by a malicious user.
After using BFG repo cleaner to clear some commits and using git reflog expire --expire=now --all && git gc --prune=now --aggressive I still can access the old timeline via direct GitLab links to specific old commits, as well as download any of "cleared" objects (from LFS). And via GitLab UI I can access to the whole old history.
In my local repo those old commits are not accessible via hash, so it's exactly remote issue, I think.
I've already tried to run Housekeeping few times, no effect.