Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

211–220 of 394 posts

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

#212

How much help is turning off the "Allow forking" option https://docs.github.com/en/repositories/managing-your-reposi... ?

If I'm a CTO how do I protect my company from this foot gun? Do I need to regularly train everyone with a GitHub account about the details, is there a setting I can toggle, or...?

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

#213
post #206

So does that mean that forked repos don't do garbage collection of unreferenced commits? If I force push and orphan a commit, I expect that will get garbage collected and be gone forever. Or if I commit a file I shouldn't have and rewrite my repo history and push up a whole new history, is the old history still hanging out forever? If true, then it seems that there is no way to delete any commits at all from any repo…

> If true, then it seems that there is no way to delete any commits at all from any repo that has any forks?

I do not believe the presence of forks matters. Or rather, your version is the initial fork.

My impression is that garbage collection is an expensive and disruptive option (to all forks) and so there's no button or API for it. Hence the recommendations to contact support if you accidentally commit an API KEY or the like (but really, you have already rotated that key, right?)

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

#214

How is this more of a vulnerability than the existence of sites like archive.org is? Isn't it just a fact of the Internet that once you make something public, you can't fully take it back later?

The third case in the article shows private forks being leaked publicly when the upstream goes public. The other two cases are indeed not worse than third-party archival, but they're still socially concerning. When you ask your own host to delete something you uploaded, you don't expect them to ignore you just because someone could have already archived it maybe. Making it harder to find can still be valuable; not al…

> When you ask your own host to delete something you uploaded, you don't expect them to ignore you just because someone could have already archived it maybe.

I've had a service say that deleting the information fully can take eight months.

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

#215

Earlier quoted context omitted.

No but I think attention should still be raised to it in the hopes they will fix it. The squeaky wheel gets the grease. https://xkcd.com/1053

I love this xkcd. We all need to embrace: Nobody has ever been impressed that you already knew something. When people share a discovery with you, it’s not about you. It’s about them and their joy of discovery. They want to share that joy with you.

If they're sharing the joy of discovery that's great. Lots of people though are gloating. "Haha, you're stupid, you didn't know X and I did". In other words, they're the ones not being charitable by assuming you don't already know X.

Trying to think of an example it usually goes something like

A: We should do X

B: No. See this document (the sharing part)

A: I wrote that document and I'm telling you we should do X (the "I already knew this" part)

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

#216

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…

I don't know if I would say it is easy as much as I'd say it is automated. I manage configuration changes to some hardware using git, and do manual backup. However, someone else came out with a script that will automate periodic commits to a GitHub account, and automates the setup.

I have a linux distribution which gives the option to allow login via a set of GitHub usernames, and will enable so by downloading each account's public SSH keys.

I don't use either of these, I don't think the second is even a good idea, but can get why its popularity and price has caused deeper integration into products. Other network backup services or login infrastructure does not have the same level of ubiquitous API nor a relevant free tier.

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

#217

Earlier quoted context omitted.

From the article: "We surveyed a few (literally 3) commonly-forked public repositories from a large AI company and easily found 40 valid API keys from deleted forks." This is how your customers get their entire cloud taken over, because you made a stupid, stupid decision and instead of fixing it when warned (repeatedly!) you instead decide to just blame the customer for not reading page 537 paragraph 3 subsection B a…

If you published a key, you must assume someone copied it and that deleting references to it is not sufficient. You must rotate that key now, and should check whether it was used improperly. This is pretty basic incident response. The thing about exposing commits that were only ever in a private repo is pretty indefensible, but not garbage collecting public commits on delete shouldn't matter.

> 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 access checks, so if you click around it'll say something like "you don't have browse access". This looks secure, but attempting access anonymously would have succeeded!

I had a customer recently where this happened -- they clicked through every Storage Account to "check" them, convinced themselves they were secure, meanwhile they had database backups with PII accessible to world+dog!

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

#218
post #196

Earlier quoted context omitted.

A fork of a private repo is private. When you make the original repo public, the fork is still a private repo, but the commits can now be accessed by hash.

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 made before the 2nd repo was made public, can still be accessed on the public repo.

Post reply on HN