Question: Does this apply to Gitlab?
frakman1 opened this issue · comments
The premise of this tool seems to hinge on the fact that Gitlab does not delete force-pushed commits and instead has them dangling in the repo for later inspection.
I was curious if the same applies to Gitlab as I have force pushed commits in the past to re-write history that would have otherwise revelealed sensitive data. i.e. Does Gitlab also not fully delete such commits? I'm not asking if this tool would work with a Gitlab repo, just if it has the same vulnerability.
The premise of this tool seems to hinge on the fact that Gitlab does not delete force-pushed commits and instead has them dangling in the repo for later inspection.
I was curious if the same applies to Gitlab as I have force pushed commits in the past to re-write history that would have otherwise revelealed sensitive data. i.e. Does Gitlab also not fully delete such commits. I'm not asking if this tool would work with a Gitlab repo, just if it has the same vulnerability.
Yes, this is the case for every Git base online version managing software, as Git has no clear definition of "garbage collection" and when to clear these dangling commits. With GitHub and its API, accessing these force-pushed commits is especially easy, even when you didn't clone or access the repository while the commit was online. We have not looked into the Gitlab API yet, but at first glance, it also has this event API endpoint, which probably has the same functionality as GitHub and would thus have the same impact on force-pushed commits. As advised in the blog post, we highly recommend that you invalidate and rotate all exposed secrets, and all sensitive data should be considered compromised no matter what.
I've made https://github.com/RichardoC/gitlab-secrets which works the same way for Gitlab. As @gcm-explo1t said this likely to be common to other git servers, though the specific discovery approaches are different.