Have you ever forked a GitHub repo? A quirk – that some argue is a significant security flaw – popped back into software engineering consciousness today*. A few things to watch out for:

1. If you fork someone else’s repository, make some commits without pushing upstream, and delete the fork – those commits will still be accessible via the original repository.
2. If a private repository is changed from private to public, commits from any private forks made up to that point, will become accessible from the now public upstream too. Subsequent changes to the private forks after the change, will not.

GitHub has documented this behaviour, but while it’s easy to argue that folks should just ‘know’ this is how forks work, I think it’s fair to say it’s not immediately obvious!

Why should you care? Two main scenarios I can see:

1. If an engineer accidentally pushes secrets to a forked public repository – even if they ‘fix’ this by deleting the entire repository, the commits in question are still accessible from the original repository.

Always. Rotate. Your. Keys. And in any instance, after removing your commits, you can ask GitHub to run a garbage collection.

2. If an organisation works to make one of their projects open source, they may commonly fork the repository prior to making it public, in order to maintain any custom modifications or allow work in private. Unfortunately this would unwittingly reveal any of these modifications up to the point of going public.

GitHub have just released the beta version of a tool that should provide a better solution for this scenario.