Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

121–130 of 394 posts

Re: Anyone can access deleted and private repository data on GitHub

#121

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.

Re: Anyone can access deleted and private repository data on GitHub

#122

Earlier quoted context omitted.

Am I really gonna get interrogated on HN for talking about automatic and redundant backup give me a break.

I wouldn't call the parent comment you're responding to an "interrogation" and I'm sorry you perceived it that way. You make a pretty extraordinary claim that local disk is better than a remote repository for storing/updating code for personal work - with no evidence to support this claim - so a followup question seems reasonable. as far as "git is distributed" I don't know if that's the case if you keep it purely lo…

I thought a person of your background (who no doubt has it all figured out) would surmise that I was talking about backing up to an external disk and not to another disk on the same laptop. And would grant another person some good faith and be able to generalize without spelling it all out for them: if the point is to back things up then maybe I can infer that other means of backup are also in the cards, like sneakernet or your own server or multiple locations. Huh

You can also back up to a remote. That is not GitHub. You know because the topic is GitHub and how promiscuous they are. Which is why I say: if you don’t need your code to be “social” you don’t need to put it on GitHub.

But even a remote repository is overkill. An automated backup plan with git bundle is automatic, after all. Set it and forget. And backups are supposed to be automated, right? I ask because you have the relevant background here.

Re: Anyone can access deleted and private repository data on GitHub

#123
post #4

I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…

To be fair, in the true git sense, if a "fork" is really just a branch, deleting the original completely would also mean deleting every branch (fork) completely

obviously not a fan of this policy though

Re: Anyone can access deleted and private repository data on GitHub

#124
post #45

Earlier quoted context omitted.

Sometimes I wonder if all the security features GitHub slathers on top of `git` lull people into a false sense of security when fundamentally they're working in a fully distributed version control system with no centralized authority. If your key is leaked the solution is to invalidate the key not just synthetically alter your version of history to pretend it never happened.

This is more of a problem if you leak private information with a commit by accident. You can't really revoke that.

You can't reach out to any machines that have pulled down that commit and forcibly delete it, either.

Re: Anyone can access deleted and private repository data on GitHub

#125
post #69

Earlier quoted context omitted.

Honest question. Submitting these types of bugs only to get a: "we have determined it is known low risk issue..." seems like they really don't want to pay for someone else's time and dedication in making their product safer. If they knew about this, was this disclosed somewhere? If not I don't see them playing a fair game. What's the motivation to do this if in the end they can have the final decision to award you or…

Security disclosures are like giving someone an unsolicited gift. The receiver is obligated to return the favor. But if you buy someone non-refundable tickets to a concert they already have tickets for, you aren't owed compensation.

[dead]

Re: Anyone can access deleted and private repository data on GitHub

#126
post #40

Earlier quoted context omitted.

I agree the 3rd is by far the worst of the offenders. But even the first two should have more visibility. For example, by notifying users during deletion of forked repos that data will still be available. The exact UX here is debatable, but I don't think security warnings buried in the docs is enough. They should be accounting for likely misunderstandings of the model.

Even if it wasn't forked, it could be cloned. Should that be part of the warning? I wouldn't mind a disclaimer when you delete a repository that any information that repository ever contained is likely to have already been downloaded and stored. Per the comment I added, I'm not sure it would really help that much, but it would not be harmful.

> Should that be part of the warning?

It couldn't hurt, but that isn't the misunderstanding I'm worried about.

As described in the first example of the article, you can make a fork, commit to it, delete your entire fork, and yet the data will still be accessible via the parent repo, even though no one ever forked or cloned or saw your fork. That is not intuitive at all.

You can say "Well just consider any data that has ever been public compromised forever", and indeed you should, but this behavior is still surprising and could bite devs even if they know they should follow the advice in that quote.

Consider a situation like this...

Dev forks, accidentally pushes a secret or some proprietary code in a commit, and immediately deletes the fork. They figure it was only up for a very short time, now it's gone, risk someone saw it is low. They don't bother rotating, because that would be a major operational pain (and yes, it shouldn't be, but for many orgs it is).

Is this dev making a mistake? Of course. That's not good security thinking. But their assessment of the risk being low might actually be correct if their very reasonable mental model of deletion were correct. But the unintuitive way GH works means that the actual risk is much higher than their reasoning led them to believe.

Re: Anyone can access deleted and private repository data on GitHub

#127

To fork private, I always just make a new repo and push to it. Looks like that behaves correctly here.

Agreed. If anything, github should remove the option to change a repo from private to public or vice versa. Force creation of a new repo with the correct settings.

Re: Anyone can access deleted and private repository data on GitHub

#128
post #99

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?

That looks like the kind of loophole that could get GH to do something about this.

Re: Anyone can access deleted and private repository data on GitHub

#129

Earlier quoted context omitted.

I wouldn't call the parent comment you're responding to an "interrogation" and I'm sorry you perceived it that way. You make a pretty extraordinary claim that local disk is better than a remote repository for storing/updating code for personal work - with no evidence to support this claim - so a followup question seems reasonable. as far as "git is distributed" I don't know if that's the case if you keep it purely lo…

I thought a person of your background (who no doubt has it all figured out) would surmise that I was talking about backing up to an external disk and not to another disk on the same laptop. And would grant another person some good faith and be able to generalize without spelling it all out for them: if the point is to back things up then maybe I can infer that other means of backup are also in the cards, like sneaker…

> I thought a person of your background (who no doubt has it all figured out) would surmise that I was talking about backing up to an external disk and not to another disk on the same laptop. And would grant another person some good faith and be able to generalize without spelling it all out for them: if the point is to back things up then maybe I can infer that other means of backup are also in the cards, like sneakernet or your own server or multiple locations. Huh

Your snark not withstanding, I actually did understand that an external disk resides outside of the laptop, and find your claim still fantastic and lacking evidence.

As for the rest of your post, you'll forgive my misunderstanding of whatever deeply nuanced point you're making here regarding backing up to a remote because of this at the end of your original post:

> local is enough.

Anyway, seems like you need to take a break. Someone of my background has better things to do than engage in a flame war with someone clearly looking for a fight over a throwaway post.

Re: Anyone can access deleted and private repository data on GitHub

#130
post #84

Earlier quoted context omitted.

But that would still means they didn't intend to fix it, hence not giving bounty is fair.

It's a bug bounty, not a "only if we have time to fix it" bounty. He found a security problem, they decided not to act on it, but it was still an acknowledged security problem

>It's a bug bounty, not a "only if we have time to fix it" bounty

It's only a bug if it's not intended

Post reply on HN