Your Private GitHub Repos Aren't as Private as You Think

Summary

This script reveals a significant GitHub vulnerability where private and deleted repository data remains accessible indefinitely through forks. Even after deletion, commits, including sensitive information like API keys, are retrievable with the commit hash. GitHub acknowledges this as an intentional feature, not a bug, which contradicts user expectations of privacy and data destruction upon deletion. The script urges GitHub to reconsider this design to align with security best practices and user trust.

Takeaways

• 🔒 GitHub's design allows anyone to access data from deleted forks, deleted repositories, and even private repositories, forever.
• 😕 Users may mistakenly believe that deleting a repository removes all associated data from public access, but this is not the case on GitHub.
• 🔍 The vulnerability stems from GitHub's repository network structure, where forks retain access to commits from the original repository, even if deleted.
• 🔑 Commit hashes, even partial ones, can be used to access deleted or private data, posing a risk to sensitive information.
• 🚫 GitHub's response to the issue confirms it as an intentional design feature, not a bug, and it's documented in their security considerations.
• 🤔 The average user perceives the separation of private and public repositories as a security boundary, which this feature contradicts.
• 💡 The GitHub archive website stores every event on GitHub, including commit hashes, making it possible to find and access deleted or private data.
• 🛑 Deleting a repository does not securely delete the data; it remains accessible through any existing forks.
• 🔄 Changing the visibility of a repository from private to public results in two separate repository networks, making past private commits in forks visible to the public.
• 🚀 For open-source projects, any code committed before the project was made public remains accessible, even in a private fork.
• 🔄 Rotating API keys or sensitive information is crucial if accidentally committed to a repository, as simple deletion is not enough to secure the data.

Q & A

What is the main concern raised in the blog post mentioned in the script?

The main concern is that anyone can access data from deleted forks, deleted repositories, and even private repositories on GitHub, and this data remains accessible forever, which is an intentional design feature of GitHub, not a bug.

How can one access data from a deleted fork on GitHub?

One can access data from a deleted fork by using the commit hash. Even if the fork is deleted, the commit is still accessible as long as the commit hash is known.

What is the vulnerability with accessing deleted fork data?

The vulnerability lies in the fact that even after a fork is deleted, the code with potentially sensitive information remains accessible using the commit hash, contrary to what one might expect after deletion.

Why is the commit hash important in accessing deleted data?

The commit hash is crucial because it uniquely identifies a commit. Knowing even a part of the commit hash can allow access to the commit's data, even if the repository or fork has been deleted.

How secure is the commit hash against brute force attacks?

The commit hash is not entirely secure against brute force attacks. A minimum of six characters is required to access the commit, which is a large number but not large enough to be considered safe against brute force.

What is GitHub Archive and how does it relate to the vulnerability?

GitHub Archive is a website that archives every event that happens on GitHub, including commits. This means that commit hashes for almost every commit on every repository that was once public are available, potentially exposing private information.

What happens when a public upstream repository that has been forked is deleted?

When a public upstream repository is deleted, instead of deleting the whole tree, GitHub reassigns the root node to one of the downstream forks, making all commits from the upstream repository still accessible via any fork.

Why does GitHub keep the data accessible even after deletion?

GitHub's design decision is based on the principle of open code collaboration, where visibility is intended to be public. This design allows forks to remain accessible even if the upstream repository is deleted.

What is the implication of this feature for users who open source a tool on GitHub?

The implication is that any code committed to a private fork before making the upstream repository public is also accessible to the public, as the commits are part of the same repository network.

What does GitHub's response to the vulnerability reveal about their stance on this feature?

GitHub's response indicates that this is an intentional design decision and is working as expected. They do not have any immediate plans to change this functionality, as it is documented in their security considerations.

What are the takeaways for users regarding the security of their repositories on GitHub?

The main takeaway is that any commit to a repository network, including the upstream repo or downstream forks, will exist forever and cannot be deleted or hidden. Users must be cautious about committing sensitive information and consider rotating any accidentally committed private keys immediately.