7 ms·

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 reposi

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 functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program. > GitHub stores the parent repository along with forks in a "repository network". It is a known behavior that objects from one network member are readable via other network members. Blobs and commits are stored together, while refs are stored separately for each fork. This shared storage model is what allows for pull requests between members of the same network. When a repository's visibility changes (Eg. public->private) we remove it from the network to prevent private commits/blobs from being readable via another network member.

tedivm 2y ago
I reported a different security issue to github, and they responded the same (although they ultimately ended up fixing it when I told them I was going to blog about the "intended behavior").
- myfonj 2y ago
  What "intended behaviour" was that, specifically?
- _heimdall 2y ago
  Did you end up getting a bug bounty out of it?
liendolucas 2y ago
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 not? To me it looks like similar to what happens with Google Play/Apple store to decide whether or not an app can be uploaded/distributed through them. Edit: I popped this up because to me is absolutely miserable from a big company to just say: "Thanks, but we were aware of this".
- deleted 2y ago
  [deleted]
- kayodelycaon 2y ago
  As the article pointed out, GitHub already publicly documented this vulnerability. My employer doesn't pay out for known security issues, especially if we have mitigating controls. A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for us. We aren't large enough to get the attention of anyone competent.
  - ipaddr 2y ago
    For both sides it turns into a net negative. Better to keep your bugs and use them when needed or sell them to others to use if possible. Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
  - giobox 2y ago
    > As the article pointed out, GitHub already publicly documented this vulnerability. I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this. If the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument: > "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
    - tptacek 2y ago
kayodelycaon 2y ago
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?
- andersa 2y ago
  No, that would be the "copy the repository" approach. Private fork is when you do it through their UI. As far as I know, it is not accessible.
- swozey 2y ago
  Because you never git pushed to the fork it's not aware of your repo, you're ok. What I don't know is if in 3 months you DO set your remote origin to that fork to for instance, pull upstream patches into your private repo, you're still not pushing, only pulling, so I would THINK they'd still never get your changes, but I don't know if git does some sort of log sync when you do a pull as well. Maybe that would wind up having the commit hash available.
- masklinn 2y ago
  It’s not. The feature here works because a network of forks known by GitHub has a unified storage, that’s what makes things like PRs work transparently and keep working if you delete the fork (kinda, it closes the PR but the contents don’t change).
- dathinab 2y ago
  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)
jeremyjh 2y ago
It would not even be that hard to fix it; private forks should always just be automatically copied on first write. You might lose your little link to the original repo, but that's not as bad as unintentionally exposing all your future content.
- sundalia 2y ago
  Yup, we can close the thread and ack that GitHub does not care.
fullstackchris 2y ago
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
- bogota 2y ago
  But a fork is really not a branch. it’s a copy of a repo with one remote pointing at the original on github but that doesn’t need to happen.
SnowflakeOnIce 2y ago
There seems to be no such thing as a "private fork" on GitHub in 2024 [1]: > A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork. [1] https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-permissions-and-visibility-of-forks#about-visibility-of-forks https://docs.github.com/en/pull-requests/collaborating-with-...
- Manuel_D 2y ago
  Not through the GitHub interface, no. But you can copy all files in a repository and create a new repository. IIRC there's a way to retain the history via this process as well.
  - make3 2y ago
    That's not the GitHub concept / almost trademark of "fork" anymore though, which is what your parent was talking about
  - a1o 2y ago
    I mean it's git, just git init, git remote add for origin and upstream, origin pointing to your private, git fetch upstream, git push to origin.
  - mckn1ght 2y ago
    You can create a private repository on GitHub, clone it locally, add the repo being "forked" from as a separate git remote (I usually call this one "upstream" and my "fork", well, "fork"), fetch and pull from upstream, then push to fork.
  - shkkmo 2y ago
    All you should have to do is just clone the repo locally and then create a blank GitHub repository, set it as the/a remote and push to it.
  - JyB 2y ago
    That’s beside the point. The article is specifically about « GitHub forks » and their shortcomings. It’s unrelated to pushing to distinct repositories not magically ´linked’ by the GH « fork feature ».
WA 2y ago
> Conclusion: don't use private forks. Copy the repository instead. My conclusion would be: don’t use GitHub.
HenryBemis 2y ago
Imho there is an issue with the word "delete". Apparently for anyone who is hosting someone else's (private and/or sensitive and/or worthy) data is to hide it from view, but keep it around "just in case" or "because we can" or "what are you gonna do about it"? I 'love' it when I see the words "hide", "archive", "remove", and other newspeak to avoid using the word "delete", since 'they' never actually delete (plus there are 1-2-5-10-forever years' of backups where your 'deleted' info can be retrieved relatively easy).
MatthewWilkes 2y ago
Same, September 2018 for me. > After some internal discussion, we have determined this is a known low risk issue. We may make this functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program. Below is a reference to our instructions for users to remove sensitive data from a repository. https://help.github.com/articles/removing-sensitive-data-from-a-repository/ https://help.github.com/articles/removing-sensitive-data-fro...

tedivm 2y ago

I reported a different security issue to github, and they responded the same (although they ultimately ended up fixing it when I told them I was going to blog about the "intended behavior").

myfonj 2y ago
What "intended behaviour" was that, specifically?
_heimdall 2y ago
Did you end up getting a bug bounty out of it?

liendolucas 2y ago

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 not? To me it looks like similar to what happens with Google Play/Apple store to decide whether or not an app can be uploaded/distributed through them. Edit: I popped this up because to me is absolutely miserable from a big company to just say: "Thanks, but we were aware of this".

deleted 2y ago
[deleted]
kayodelycaon 2y ago
As the article pointed out, GitHub already publicly documented this vulnerability. My employer doesn't pay out for known security issues, especially if we have mitigating controls. A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for us. We aren't large enough to get the attention of anyone competent.
- ipaddr 2y ago
  For both sides it turns into a net negative. Better to keep your bugs and use them when needed or sell them to others to use if possible. Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
- giobox 2y ago
  > As the article pointed out, GitHub already publicly documented this vulnerability. I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this. If the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument: > "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
  - tptacek 2y ago

kayodelycaon 2y ago

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?

andersa 2y ago
No, that would be the "copy the repository" approach. Private fork is when you do it through their UI. As far as I know, it is not accessible.
swozey 2y ago
Because you never git pushed to the fork it's not aware of your repo, you're ok. What I don't know is if in 3 months you DO set your remote origin to that fork to for instance, pull upstream patches into your private repo, you're still not pushing, only pulling, so I would THINK they'd still never get your changes, but I don't know if git does some sort of log sync when you do a pull as well. Maybe that would wind up having the commit hash available.
masklinn 2y ago
It’s not. The feature here works because a network of forks known by GitHub has a unified storage, that’s what makes things like PRs work transparently and keep working if you delete the fork (kinda, it closes the PR but the contents don’t change).
dathinab 2y ago
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)

jeremyjh 2y ago

It would not even be that hard to fix it; private forks should always just be automatically copied on first write. You might lose your little link to the original repo, but that's not as bad as unintentionally exposing all your future content.

sundalia 2y ago
Yup, we can close the thread and ack that GitHub does not care.

fullstackchris 2y ago

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

bogota 2y ago
But a fork is really not a branch. it’s a copy of a repo with one remote pointing at the original on github but that doesn’t need to happen.

SnowflakeOnIce 2y ago

There seems to be no such thing as a "private fork" on GitHub in 2024 [1]: > A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork. [1] https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-permissions-and-visibility-of-forks#about-visibility-of-forks https://docs.github.com/en/pull-requests/collaborating-with-...

Manuel_D 2y ago
Not through the GitHub interface, no. But you can copy all files in a repository and create a new repository. IIRC there's a way to retain the history via this process as well.
- make3 2y ago
  That's not the GitHub concept / almost trademark of "fork" anymore though, which is what your parent was talking about
- a1o 2y ago
  I mean it's git, just git init, git remote add for origin and upstream, origin pointing to your private, git fetch upstream, git push to origin.
- mckn1ght 2y ago
  You can create a private repository on GitHub, clone it locally, add the repo being "forked" from as a separate git remote (I usually call this one "upstream" and my "fork", well, "fork"), fetch and pull from upstream, then push to fork.
- shkkmo 2y ago
  All you should have to do is just clone the repo locally and then create a blank GitHub repository, set it as the/a remote and push to it.
- JyB 2y ago
  That’s beside the point. The article is specifically about « GitHub forks » and their shortcomings. It’s unrelated to pushing to distinct repositories not magically ´linked’ by the GH « fork feature ».

WA 2y ago

> Conclusion: don't use private forks. Copy the repository instead. My conclusion would be: don’t use GitHub.

HenryBemis 2y ago

Imho there is an issue with the word "delete". Apparently for anyone who is hosting someone else's (private and/or sensitive and/or worthy) data is to hide it from view, but keep it around "just in case" or "because we can" or "what are you gonna do about it"? I 'love' it when I see the words "hide", "archive", "remove", and other newspeak to avoid using the word "delete", since 'they' never actually delete (plus there are 1-2-5-10-forever years' of backups where your 'deleted' info can be retrieved relatively easy).

MatthewWilkes 2y ago

Same, September 2018 for me. > After some internal discussion, we have determined this is a known low risk issue. We may make this functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program. Below is a reference to our instructions for users to remove sensitive data from a repository. https://help.github.com/articles/removing-sensitive-data-from-a-repository/ https://help.github.com/articles/removing-sensitive-data-fro...