Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

81–90 of 394 posts

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

#81

Earlier quoted context omitted.

For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear. I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model. The third strikes me as counter-intuitive and hard to reason about. P.S. If you publish your keys or access tokens for well known services to GitHub and you are prom…

> For the first two, git is based on content addressable storage, so it makes sense that anything that is every public will never disappear. this isn't quite right content addressable storage is just a mean of access it does - not imply content cannot be deleted - not imply content cannot be access managed you could apply this to a git repo itself (like making some branches private and some not) but more important fo…

You're right that I shouldn't have given the impression that content addressed storage means as a technical matter that public content must never disappear. The phrasing was a bit sloppy. GitHub could, as a technical matter, choose to hide content that had previously been made public.

Nonetheless, given that GitHub exists to facilitate both anonymously pulling the entire history of the repository, and given that any forks would contain the full contents of that repository, it is very natural that GitHub would take the "once public always public" line.

> and I mean commits made to private repositories being public is always a security vulnerability no matter how much github claims it's intended

I specifically said the third use case was different, because it is the one that doesn't involve you explicitly choosing to publish the commits that contain your private information. I did not and would not defend GitHub on that point.

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

#82
commits done to private repose being public (point 2&3) is always a non minor security vulnerability IMHO

it doesn't matter if it's behaving as intended or how there are forks

also point 1 implies that github likely doesn't properly GCes there git which could have all kinds of problematic implications beyond the point 1 wrt. purging accidental leaked secrets or PI....

all in all it just shows github might not take privacy security serious ... which is kinda hilarious given that private repo using customers tend to be the paying customers

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

#83

Earlier quoted context omitted.

For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear. I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model. The third strikes me as counter-intuitive and hard to reason about. P.S. If you publish your keys or access tokens for well known services to GitHub and you are prom…

> git is based on content addressable storage, so it makes sense that anything that is every public will never disappear. No. That doesn't make sense. It only sounds vaguely plausible at first because content addressable storage often means a distributed system where hosting nodes are controlled by multiple parties. That's not the case here, we're only talking about one host. Imagine we were talking about a (hypothet…

Since Netflix neither allows anonymous users to fully download Frozen without DRM, nor allows authorized users to upload derivative works that are then redistributed to the public, I think there may be some relevant differences here.

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

#84
post #48

Earlier quoted context omitted.

Based on some (admittedly not very thorough) search, this documentation was posted in 2021, three years after my report.

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

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

#85
post #17

Surprised at the comments minimizing this. I've used github for a long time, would not have expected these results, and was unnerved by them. I'd recommend reading the article yourself. It does a good job explaining the vulnerabilities.

For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear. I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model. The third strikes me as counter-intuitive and hard to reason about. P.S. If you publish your keys or access tokens for well known services to GitHub and you are prom…

> For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear.

No one can, with a straight face, say that they don’t restrict access because “this is just how the technology works”. Doesn’t matter if it is content addressable or an append-only FS or whatever else.

Even for some technology where the data lives forever somewhere (it doesn’t according to Git; GitHub has a system which keeps non-transitively referenced commits from being garbage collected), the non-crazy thing is to put access policy logic behind the raw storage fetch.

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

#86

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.

It also applies to this situation:

    1. Create a private repo R
    2. Create a private fork F of R
    3. Push commits to the fork F
    4. Make R public
The commits pushed to F prior to R being made public will become de facto public, even though F has always been a private fork. The post makes clear that commits pushed to F after R is made public are placed into a separate, private fork network.

So basically, if you ever intend to open source anything, never do it to an existing private repo. Always start a from-scratch repo to be the root of your new public project.

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

#87
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…

What does "private fork" mean in this context? I created a fork of a project by cloning it to my own machine and set origin to an empty private repository on GitHub. I manually merge upstream changes on my machine. Is my repository accessible?

then it's fine

the issue is the `fork` mechanism of github is not semantically like a `git clone`

it's more like creating a larger git repo in which all forks weather private or not are contained and which doesn't properly implement access management (at least point 2&3 wouldn't be an issue if they did)

there are also some implications form point 1 that forks do in some way infer with gc-ing orphan commits (e.g. the non synced commits in he deleted repo in point 1) at least that should be a bug IMHO one which also costs them storage

(also to be clear for me 2&3 are security vulnerabilities no matter if they are classified as intended behavior)

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

#88

commits done to private repose being public (point 2&3) is always a non minor security vulnerability IMHO it doesn't matter if it's behaving as intended or how there are forks also point 1 implies that github likely doesn't properly GCes there git which could have all kinds of problematic implications beyond the point 1 wrt. purging accidental leaked secrets or PI.... all in all it just shows github might not take pr…

You’re right that they don’t let commits get GC. They jump through hoops in order to keep commits that are not transitively referenced from being garbage collected. Just assume that every commit is kept around for “auditing”.

One GitHub employee even contributed a configuration to Git which allows you to do the same thing: run a program or feed a file which tells the GC what nodes to not traverse.

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

#89
post #55

Most of this report is just noise. GitHub repos are public. Public stuff can be shared. Public stuff shared previously and then deleted is "still available", but it was shared previously and not really subject to security analysis. The one thing they seem to be able to show is that commits in private branches show up in the parent repository if you know the SHAs. And that seems like a real vulnerability. But AFAICT i…

> it also requires that you know the commit IDs, which is not something you can get via brute forcing the API

Well, GitHub accepts abbreviations down to as short as four hex digits... as long as there's no collision with another commit, that's certainly feasible. Even if there is collision, once you have the first four characters you can just do a breadth-first search

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

#90
People are so preoccupied with putting the code on GitHub. It’s like it doesn’t exist before it’s on GitHub.

If you’re not gonna share it then it hardly matters. Use a backup drive.

Git is distributed. You don’t have to put your dotfiles on GitHub. Local is enough.

Post reply on HN