3 ms·

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

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
  The problem with this line of argument is that the fundamental workings of git are also surprising to people, such that they routinely attempt to address mistaken hazmat commits by simple reverts. If at bottom this whole story is just that git is treacherous, well, yeah, but not news. There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.
  - Cpoll 2y ago
    Is "git" relevant here? Forking isn't a git concept, and none of this behaviour has much to do with git; it's all GitHub. Also, you can revoke an API key, but you can't revoke a company-proprietary algorithm that you implemented into a fork of a public project.
    - tptacek 2y ago
      Like I said: if you can't revoke the thing you committed, you need to get in touch with Github and have them remove it. That's a thing they do.
      - Cpoll 2y ago
        Sure, but the whole point of the article is that people don't know their "private" forks aren't private. You can't get in touch with GitHub if you've never had any indication that anything's wrong. The solution for that is better UX.
    - schrodinger 2y ago
      aside: I think it's questionable to say that forking isn't a git concept. it's just a branch on a different upstream. Those two upstreams could simply be two different folders on your machine, or shared server. I supposed the branding and UI for it could be a counter argument, but then again Github allows regular branch creation / committing / merging in their UI. Their main value add (not downplaying it—it's huge) on top of git (besides ancillary things like CI / linters) is the ability to comment on a branch's diff, i.e. a PR Review.
      - giobox 2y ago
        There's an entire custom UX flow for forking on GH that is not part of git at all. I think its very fair here to discuss "fork" in the specific sense Github uses it, as its what has lead to some of the issues discussed. There are absolutely means of providing fork functionality that don't have some of the problems we are discussing, but that's not how GH chose to build it.
- gowld 2y ago
  Two thinks can be true (and are) 1. GitHub has a nasty privacy/security hole, where commonsense expectations about the meanings of common words are violated by the system. 2. Github has publicly announced that they don't care about this part of user data security (private code), so won't pay people to know tell them what they alreay know and announced. Github won't pay you to tell them they are wrong when everyone alreay knows.
oxfordmale 2y ago
As the author pointed out, the documentation was written three years after he reported it. Beyond that is is also a batshit crazy implementation. Just I imagine AWS would still allow AWS credentials to give access to a deleted account
- account42 2y ago
  The expectations for AWS and public repository hosting are not the same. If you leaked something to a public GitHub repo you should assume that it has been cloned the second you pushed it.
  - oxfordmale 2y ago
    This is about access to private repos, not public ones: "Anyone can access deleted and private repository data on GitHub"

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
The problem with this line of argument is that the fundamental workings of git are also surprising to people, such that they routinely attempt to address mistaken hazmat commits by simple reverts. If at bottom this whole story is just that git is treacherous, well, yeah, but not news. There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.
- Cpoll 2y ago
  Is "git" relevant here? Forking isn't a git concept, and none of this behaviour has much to do with git; it's all GitHub. Also, you can revoke an API key, but you can't revoke a company-proprietary algorithm that you implemented into a fork of a public project.
  - tptacek 2y ago
    Like I said: if you can't revoke the thing you committed, you need to get in touch with Github and have them remove it. That's a thing they do.
    - Cpoll 2y ago
      Sure, but the whole point of the article is that people don't know their "private" forks aren't private. You can't get in touch with GitHub if you've never had any indication that anything's wrong. The solution for that is better UX.
  - schrodinger 2y ago
    aside: I think it's questionable to say that forking isn't a git concept. it's just a branch on a different upstream. Those two upstreams could simply be two different folders on your machine, or shared server. I supposed the branding and UI for it could be a counter argument, but then again Github allows regular branch creation / committing / merging in their UI. Their main value add (not downplaying it—it's huge) on top of git (besides ancillary things like CI / linters) is the ability to comment on a branch's diff, i.e. a PR Review.
    - giobox 2y ago
      There's an entire custom UX flow for forking on GH that is not part of git at all. I think its very fair here to discuss "fork" in the specific sense Github uses it, as its what has lead to some of the issues discussed. There are absolutely means of providing fork functionality that don't have some of the problems we are discussing, but that's not how GH chose to build it.
gowld 2y ago
Two thinks can be true (and are) 1. GitHub has a nasty privacy/security hole, where commonsense expectations about the meanings of common words are violated by the system. 2. Github has publicly announced that they don't care about this part of user data security (private code), so won't pay people to know tell them what they alreay know and announced. Github won't pay you to tell them they are wrong when everyone alreay knows.

oxfordmale 2y ago

As the author pointed out, the documentation was written three years after he reported it. Beyond that is is also a batshit crazy implementation. Just I imagine AWS would still allow AWS credentials to give access to a deleted account

account42 2y ago
The expectations for AWS and public repository hosting are not the same. If you leaked something to a public GitHub repo you should assume that it has been cloned the second you pushed it.
- oxfordmale 2y ago
  This is about access to private repos, not public ones: "Anyone can access deleted and private repository data on GitHub"