4

Asking for a friend.

Scenario

Confidential information has been pushed to a public github repository by accident. As soon as the commiter noticed the failure he decided to override git history with push -f to remove the information from the web.

Problem

  • The confidential information is still accessible via git reflog at github. So the staff at github is still able to access the information.

  • Even worse, if the commiter has put a reference in the initial commit message, e.g. referencing an issue using the #-sign, github would automatically put a link to the commit into that issue. In this case the overridden information is still accessible via the github frontend.

Question

  • Is it possible to modify/delete the reflog of a remote git or github repository?
  • If it is not possible. What would you do in the given scenario? Delete the issue with the reference to the first commit? Delete the whole repository? Whate else?
jschnasse
  • 8,526
  • 6
  • 32
  • 72
  • 2
    Read the [documentation](https://help.github.com/articles/removing-sensitive-data-from-a-repository/) which says that any data pushed to GitHub is to be considered compromised. There is a chance that someone else already pulled, cloned, etc. the bad branch/commit. – Tim Biegeleisen Dec 12 '17 at 10:53
  • It seems that it is [not possible to delete github issues](https://github.com/isaacs/github/issues/253). That means, if confidential data is referenced in an issue you have to email to github and ask for help. – jschnasse Dec 13 '17 at 08:07
  • It is not possible to delete an issue from github by now https://stackoverflow.com/questions/3081521/how-to-completely-remove-an-issue-from-github – jschnasse Dec 13 '17 at 08:28
  • Here are similar questions, I didn't found at first, because I was searching for "reflog". https://stackoverflow.com/questions/24720986/remove-deleted-commit-that-references-an-issue and https://stackoverflow.com/questions/24720986/remove-deleted-commit-that-references-an-issue – jschnasse Dec 13 '17 at 09:11
  • In the meantime github has implemented the deletion of issues - See: https://github.com/isaacs/github/issues/253 – jschnasse Nov 05 '20 at 12:52

1 Answers1

4

As long as plain Git is concerned, no it is not possible.

But on the other hand, "remote" repositories — those everyone pushes to and fetches from — are "bare", and bare repositories are initialized with reflog disabled by default.

As to Github, this is completely another story as they do not serve the repositories using "plain" Git, and consequently server-side management of the repositories is really outside of Git realm — please see what the Github docu says:

'Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised.'

What to do next? If data has been compromised

1) re-write the history using any of the available tools;

2) Force-push the result to overwrite what's already there.

3) Contact Github for further assistance. If that happened at your $dayjob, this should be an official contact. Before doing that, whoever is to contact Github should read their "terms and conditions". When contacting, one should politely ask about what possible repercussions are, and whether it's possible to prevent possible spreading of the compromised information using ways other than fetching from the repo (which was already fixed). I mean, say, repo replicas or backups or whatnot internal to Github

jschnasse
  • 8,526
  • 6
  • 32
  • 72
kostix
  • 51,517
  • 14
  • 93
  • 176
  • Thank you, I did't know about "bare repositories". [Github docu](https://help.github.com/articles/removing-sensitive-data-from-a-repository/) says: *'Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised.'* (thx to [Tim](https://stackoverflow.com/users/1863229/tim-biegeleisen) for pointing this out). But what additional steps should follow in the github case? Deleting the repo? – jschnasse Dec 12 '17 at 11:22
  • @jschnasse, well, the answer is on that same page — [here is is](https://help.github.com/articles/removing-files-from-a-repository-s-history/). Basically it amounts to "1) re-write the history using any of the available tools; 2) Force-push the result to overwrite what's already there." What follows, is that whatever was pushed is obviously fetchable, and that's precisely what "consider … to be compromised" means. – kostix Dec 12 '17 at 11:54
  • @jschnasse, so I'd do the following. Contact Github for further assistance. If that happened at your $dayjob, this should be an official contact. Before doing that, whoever is to contact Github should read their "terms and conditions". When contacting, one should politely ask about what possible repercussions are, and whether it's possible to prevent possible spreading of the compromised information using ways other than fetching from the repo (which was already fixed). I mean, say, repo replicas or backups or whatnot internal to Github. – kostix Dec 12 '17 at 11:57
  • 2
    @jschnasse while IANAL, I'd note that "there's no cloud, there's just someone else's computer", so when you decided to host your code not on your own premises, you basically signed for such "oopsies" to be hardly correctable. So basically since you do not appear to have an NDA signed with Github, you just may ask them something, that's all. – kostix Dec 12 '17 at 11:59
  • Hm, sounds reasonable! Should we incorporate the comments into the answer? – jschnasse Dec 12 '17 at 12:39
  • @jschnasse, I have no idea. Of course, feel free to refer to this resource—it's open after all, but please don't just do a "link drop" on them! Carefully formulate the problem statement so that it can be read and understood completely in isolation from this discussion. Linking to it at the end is fine. – kostix Dec 12 '17 at 14:27
  • 3
    Keep in mind that GitHub probably has a legal disclaimer regarding information that has been pushed to their public repo. They likely won't (and can't) guarantee the privacy of your data. The best solution here is to not push such data in the first place. – Tim Biegeleisen Dec 13 '17 at 08:09
  • 1
    Actually, point 4 of the T&Cs says: «You grant us and our legal successors the right to … make incidental copies as necessary to … provide the Service. This includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users; and perform it, in case Your Content is something like music or video.». That's what I would expect, and why suggested to contact the staff to limit those use cases if at all possible. – kostix Dec 13 '17 at 08:20