Anyone can access deleted and private repository data on GitHub

Post by epolanski » Thu, Jul 25, 2024, 9:41 AM UTC

hackerbirds wrote: post #44

Users should never be expected to know these gotchas for a feature called "private", documented or not. It's disappointing to see GitHub calling it a feature instead of a bug, to me it just shows a complete lack of care about security. Privacy features should _always_ have a strict, safe default. In the meantime I'll be calling "private" repos "unlisted", seems more appropriate

Post by andersa » Thu, Jul 25, 2024, 9:49 AM UTC

account42 wrote: post #288

liendolucas wrote: post #25

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…

Disagree. This is obviously a deliberate design choice with obvious implications. Expecting a bounty for reporting this is unreasonable. These kind of beg bounties are exactly what gives security "researchers" a bad name. The security implications are also minor. The only problem really is with making a fork of a private repo public - that should only make what exists in that fork public and not any other objects. So…

Post by andersa » Thu, Jul 25, 2024, 9:59 AM UTC

ndriscoll wrote: post #233

jiggawatts wrote: post #217

Earlier quoted context omitted.

> If you published a key Why would anyone think that a private fork is "published"!? This is the footgun here: The UI is telling you that nobody can see the secrets you committed to your private copy , but actually it is widely accessible. A similar example of UI-vs-reality mismatch that I've noticed recently is the Azure Store Account "public" visibility. By default, it uses your authenticated account for RBAC acces…

The bit you quoted is referring to public forks that were deleted. That sounds like a non-issue to me, and I'm not at all surprised that 1. Public "forks" are just namespaced branches that share an underlying repo 2. They don't run the garbage collector all the time I'd be surprised if those weren't true. Like I said, the behavior with private forks sounds indefensible. The OP is mixing together multiple things. Bein…

Post by keybored » Thu, Jul 25, 2024, 10:02 AM UTC

hughesjj wrote: post #165

keybored wrote: post #122

Earlier quoted context omitted.

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…

GitHub, for better or worse, has been one of the easiest ways to backup configuration for ..decades now. It's more secure than sending an email to yourself, Google drive still doesn't have an official linux client, AWS is too enterprisey for a handful of small backup files, and git is incredibly easy to set up + available on so many computers. I completely get why people would want to use GitHub for a low friction wa…

Post by Rizz » Thu, Jul 25, 2024, 10:24 AM UTC

thrdbndndn wrote: post #219

I cannot access the commit https://github.com/trufflesecurity/trufflehog/commit/7bc0b shown in one of the pictures in the article (right before "Where do you get these hash values") despite this repo is even public. What gives?