301–310 of 394 posts
Earlier quoted context omitted.
Yep, I see GitHub as "public only" hosting, and if I want to host something private, I will choose another vendor.
The noted issue looks to be applicable to forks only, not to all private repos.
However, if they "don't care" about such an issue, how can I trust them to care about other stuff?
The biggest gotcha here is probably that if you start of with a private repo and a private fork, making the repo public also makes the fork "public". GitHub may very well say that this is working as intended, but if it truly is then you should be forced to make both the repo and fork public at the same time. Essentially "Making repo R public will make the following forks public as well 'My Fork', 'Super secret fork',…
I agree. The other cases may be mildly surprising, but ultimately fall firmly into the category of "once public on the internet, always public." Deleting a repo or fork or commit doesn't revoke an access key that was accidentally committed, and an access key being public for even a microsecond should be assumed to have been scraped and usable by a malicious actor.
The issue here is that if you have a private repo and a private fork of that repo. If you make the private repo public and keep the fork private, then you are not explicitly told that your fork is actually public, whether you want to or not.
Earlier quoted context omitted.
According to the screenshot in the documentation, though, new commits made to the fork will not be accessible by hash. So private feature branches in forks may be accessible via the upstream that was changed to public, if those branches existed at the time the upstream's visibility changed, but new feature branches made after that time won't be accessible.
OK but say a company has a private, closed source internal tool, and they want to open-source some part of it. They fork it and start working on cleaning up the history to make it publishable. After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. According to this article, any commit on either repo which was m…
I know this might look like a valid approach on the first glance but... it is stupid for anyone who knows how git or GitHub API works? Remote (GitHub's) reflog is not GC'd immediately, you can try to get commit hashes from events history via API, and then try to get commits from reflog.
Can this be used to host illegal content? I.e.: fork a popular repo, commit a pirated book to the fork, delete the fork, use the original repo to access the pirated book? What would github do after receiving a DMCA request in that case?
Earlier quoted context omitted.
As the author pointed out, the documentation was written three years after he reported it. Beyond that is is also a batshit crazy implementation. Just I imagine AWS would still allow AWS credentials to give access to a deleted account
The expectations for AWS and public repository hosting are not the same. If you leaked something to a public GitHub repo you should assume that it has been cloned the second you pushed it.
"Anyone can access deleted and private repository data on GitHub"
Really the only semi-interesting part of this is "if you make a private repo public, data from other private forks might be discoverable", but even that seems pretty minor, and the best practice for taking private repos public is to copy the data into a new repo anyway.
Even after a private repo is made public, it's common practice for new functionality to be worked on in private until it's ready.
Clearly a POLA violation (principle of least astonishment)
This walks like a dark pattern and quacks like a dark pattern. People's entire livelihoods are at stake and they don't care. Most likely because plausible deniability and obscure TOS rights of how and when the code is used is more valuable to them than the reputation hit. It is hard to imagine this is very hard to fix.
No they aren't.
Earlier quoted context omitted.
Anyone at your company and just push to a public git repository at any time. Nothing stopping them except threat of consequences.
So? Employees with access to sensitive data are capable of leaking that data. News at eleven! And anyone in the world can pull what was pushed to a public git repo before you delete it. You should always assume that has happened.
"Anyone can access deleted and private repository data on GitHub"
I learned about it years ago when I accidentally pushed secrets to the repo. When after rebasing and force pushing to the branch I was still able to access that commit, we decided to stop using GitHub.
Further, even if you had managed to delete the secrets from the repo you have to assume that others already copied them and rotat your keys anwyay.