Looks like it’s just random commenters taking random guesses because those have happened before.
What is a “repository reset”? One commenter writes:
There was a temporary similar “outage” back in July with rewritten history, apparently something inappropriate was recorded in the repo history they wanted cleaned out. The repo came back after that. I have no idea if this is the same thing, or if they just got tired of maintaining it.
Seems strange to me. You can prep locally and then force-push. I don’t see why rewriting history would require taking the repository down.
Plus won’t the forks on GitHub keep the history before the “reset”?
Afaik, forks on GitHub are basically the same underlying repository, just a branch associated with another user. They won’t be able to really purge anything from these other branches.
Plus anyone who has a local copy of the repo or an automatic mirror somewhere else, will have the changes available.
It makes sense, but once it’s pushed there is no way to know if it’s been cloned or kept somewhere else. The only real mitigation is to rotate the keys or password that was leaked.
If it’s something else you can’t rotate, you’re screwed.
Looks like it’s just random commenters taking random guesses because those have happened before.
What is a “repository reset”? One commenter writes:
Seems strange to me. You can prep locally and then force-push. I don’t see why rewriting history would require taking the repository down.
Plus won’t the forks on GitHub keep the history before the “reset”?
Afaik, forks on GitHub are basically the same underlying repository, just a branch associated with another user. They won’t be able to really purge anything from these other branches.
Plus anyone who has a local copy of the repo or an automatic mirror somewhere else, will have the changes available.
Yes, forks remain as they are. Yes, the fork network has a shared data repository on GitHub.
Consequently, rewritten history will break history compatibility, possibly requiring manual fixups on forks or work based on it.
If he pushed something he shouldn’t have online then taking it offline immediately makes a lot of sense.
It makes sense, but once it’s pushed there is no way to know if it’s been cloned or kept somewhere else. The only real mitigation is to rotate the keys or password that was leaked.
If it’s something else you can’t rotate, you’re screwed.
https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
The point wasn’t that it’s not accessible but limiting the damage while you still can.