Wow! This is significant! This publication is going to kickoff an arms race of brute forcing popular public repos owned/maintained by companies that have a premium SaaS offering of the same...
Wow! This is significant! This publication is going to kickoff an arms race of brute forcing popular public repos owned/maintained by companies that have a premium SaaS offering of the same product as the repo. It’s a fairly common business model today.
If they follow good security practices (hah!) then any keys they committed should have rotated long ago anyway. The biggest problem here is just that private source code isn't so private. Premium...
If they follow good security practices (hah!) then any keys they committed should have rotated long ago anyway. The biggest problem here is just that private source code isn't so private.
Premium SaaS offerings are largely support-based, so if someone wanted to pirate it and run it on their own, well, they may have been able to do that anyway for a lot of things. They just wouldn't get any support, and it wouldn't be legal, which are the two things that people (companies) who pay for SaaS tend to want.
That’s exactly what I mean. Anything that’s been forked on GitHub is going to be publicly available eventually. The keys problem can be solved for rather quickly but the loss of proprietary...
That’s exactly what I mean. Anything that’s been forked on GitHub is going to be publicly available eventually. The keys problem can be solved for rather quickly but the loss of proprietary intellectual property is devastating for a business. Imagine spending all the time, effort and money on research and development of a project and can’t reap the rewards because your competitors didn’t have to spend the capital to get the same solution for free.
Well yeah, in an ideal world, everybody would read the documentation (lol), but in that scenario nobody would ever leak confidential keys into source code, either (double lol). I think it’s...
Well yeah, in an ideal world, everybody would read the documentation (lol), but in that scenario nobody would ever leak confidential keys into source code, either (double lol).
I think it’s completely fine if GitHub wants the fork network technology to work like that, it’s a well-thought design in all likeliness, but in that case they should announce its caveats more visibly. The people who would read up on how forks and private repositories work when intertwined are probably already the least likely demographic to leak secrets…
An issue I do see remaining in that scenario is non-FOSS or partially open sourced software based on an open upstream, as was mentioned in the article. The solution for the case of keeping their “premium offering” products’ code private, if that’s something the company wants to do, seems to be moving it elsewhere from the getgo, to be frank.
GitHub prevents making part of the fork network public while any part is [currently] private. Accessing commits from deleted forks is surprising, but it shouldn't really be considered a new...
This is mildly concerning if you're not expecting it, but I don't think there's much to worry about here. If any part of the fork network is public then all commits in the entire network are visible - but if none of the fork network is public, then none of the fork network is visible.
GitHub prevents making part of the fork network public while any part is [currently] private.
Accessing commits from deleted forks is surprising, but it shouldn't really be considered a new vulnerability. If you committed a secret to a fork of a public repository, you committed a secret to a public repository. That secret is already public. You must delete the commit, not the branch, and not the repo. You should treat that secret as compromised in any case.
This might have an impact if you have multiple orgs and multiple developer roles with given permissions - a developer might gain access to commits in an org for which they don't have permissions. However doing this requires they have permissions in at least one org which can see the repository.
Trying it myself
To double check all this:
I create a private repo from a public template. I can view commits on the template via my private repo, but I cannot view private commits on the public template repo. There doesn't seem to be a "real" connection so things are fine; I think those commits from the template are just waiting to be garbage-collected.
I create a private fork of my private repo (in another org that I own). I can view any commit from either repository, which is not intuitive, but all is private so things are fine.
I try to make the private fork public. GitHub does not allow this: "For security reasons, you cannot change the visibility of a fork." Fair enough, things are fine.
I make the upstream public. GitHub severs the connection to the fork and duplicates history - there is no longer a connection via the fork network. Any commit which was not in upstream before making it public is not visible via the public repository. I also can no longer view public upstream commits via the private fork because it is not in the fork network.
I try to create a new private fork of the public upstream. GitHub does not allow this: there simply is no way to choose the visibility of the fork. I try to make the fork private after creating it. GitHub does not allow this: "For security reasons, you cannot change the visibility of a fork."
I delete the upstream repository. GitHub severs the connection to the fork and duplicates history. Any commit which was not in the fork before deleting upstream is lost.
This behavior that I observed is different that what the article describes. I don't know if that means GitHub has changed this since the article was published or if I did something else differently.
Ah, the trick is that if you delete the private fork before making upstream public, GitHub never severs the connection (the fork is gone so there is no connection to sever) so the commits in the private repository are stuck in the fork network of upstream. When upstream is made public, it brings those along with it.
GitHub could fix this by maintaining some record after a fork repository is deleted that it was private, so when upstream is made public those commits are dropped as they are when the fork still exists.
I don't think there's anything to be done about the behavior when everything is public. You have to treat any secret ever committed to a public repository as compromised. That's always been recommended security practice.
Thank you for doing the detailed testing to confirm! :D This does bring down the severeness, I think, since the scenario shouldn’t be all too common. And in the end, like you said – rotate out...
Thank you for doing the detailed testing to confirm! :D
This does bring down the severeness, I think, since the scenario shouldn’t be all too common. And in the end, like you said – rotate out anything that’s ever gotten leaked into source code anyways, so this isn’t a “new” issue.
Damn! I wonder if, despite it being an “intended“ feature, GitHub will pivot to changing the way this behaves now that it’s being publicized (and publicly critized).
Damn! I wonder if, despite it being an “intended“ feature, GitHub will pivot to changing the way this behaves now that it’s being publicized (and publicly critized).
Wow! This is significant! This publication is going to kickoff an arms race of brute forcing popular public repos owned/maintained by companies that have a premium SaaS offering of the same product as the repo. It’s a fairly common business model today.
If they follow good security practices (hah!) then any keys they committed should have rotated long ago anyway. The biggest problem here is just that private source code isn't so private.
Premium SaaS offerings are largely support-based, so if someone wanted to pirate it and run it on their own, well, they may have been able to do that anyway for a lot of things. They just wouldn't get any support, and it wouldn't be legal, which are the two things that people (companies) who pay for SaaS tend to want.
That’s exactly what I mean. Anything that’s been forked on GitHub is going to be publicly available eventually. The keys problem can be solved for rather quickly but the loss of proprietary intellectual property is devastating for a business. Imagine spending all the time, effort and money on research and development of a project and can’t reap the rewards because your competitors didn’t have to spend the capital to get the same solution for free.
This is less "this is wrong and needs to be fixed", and more "this works differently than you might think, so you should be careful".
Well yeah, in an ideal world, everybody would read the documentation (lol), but in that scenario nobody would ever leak confidential keys into source code, either (double lol).
I think it’s completely fine if GitHub wants the fork network technology to work like that, it’s a well-thought design in all likeliness, but in that case they should announce its caveats more visibly. The people who would read up on how forks and private repositories work when intertwined are probably already the least likely demographic to leak secrets…
An issue I do see remaining in that scenario is non-FOSS or partially open sourced software based on an open upstream, as was mentioned in the article. The solution for the case of keeping their “premium offering” products’ code private, if that’s something the company wants to do, seems to be moving it elsewhere from the getgo, to be frank.
This is mildly concerning if you're not expecting it, but I don't think there's much to worry about here. If any part of the fork network is public then all commits in the entire network are visible - but if none of the fork network is public, then none of the fork network is visible.GitHub prevents making part of the fork network public while any part is [currently] private.
Accessing commits from deleted forks is surprising, but it shouldn't really be considered a new vulnerability. If you committed a secret to a fork of a public repository, you committed a secret to a public repository. That secret is already public. You must delete the commit, not the branch, and not the repo. You should treat that secret as compromised in any case.
This might have an impact if you have multiple orgs and multiple developer roles with given permissions - a developer might gain access to commits in an org for which they don't have permissions. However doing this requires they have permissions in at least one org which can see the repository.
Trying it myself
To double check all this:
I create a private repo from a public template. I can view commits on the template via my private repo, but I cannot view private commits on the public template repo. There doesn't seem to be a "real" connection so things are fine; I think those commits from the template are just waiting to be garbage-collected.
I create a private fork of my private repo (in another org that I own). I can view any commit from either repository, which is not intuitive, but all is private so things are fine.
I try to make the private fork public. GitHub does not allow this: "For security reasons, you cannot change the visibility of a fork." Fair enough, things are fine.
I make the upstream public. GitHub severs the connection to the fork and duplicates history - there is no longer a connection via the fork network. Any commit which was not in upstream before making it public is not visible via the public repository. I also can no longer view public upstream commits via the private fork because it is not in the fork network.
I try to create a new private fork of the public upstream. GitHub does not allow this: there simply is no way to choose the visibility of the fork. I try to make the fork private after creating it. GitHub does not allow this: "For security reasons, you cannot change the visibility of a fork."
I delete the upstream repository. GitHub severs the connection to the fork and duplicates history. Any commit which was not in the fork before deleting upstream is lost.
This behavior that I observed is different that what the article describes. I don't know if that means GitHub has changed this since the article was published or if I did something else differently.Ah, the trick is that if you delete the private fork before making upstream public, GitHub never severs the connection (the fork is gone so there is no connection to sever) so the commits in the private repository are stuck in the fork network of upstream. When upstream is made public, it brings those along with it.
GitHub could fix this by maintaining some record after a fork repository is deleted that it was private, so when upstream is made public those commits are dropped as they are when the fork still exists.
I don't think there's anything to be done about the behavior when everything is public. You have to treat any secret ever committed to a public repository as compromised. That's always been recommended security practice.
Thank you for doing the detailed testing to confirm! :D
This does bring down the severeness, I think, since the scenario shouldn’t be all too common. And in the end, like you said – rotate out anything that’s ever gotten leaked into source code anyways, so this isn’t a “new” issue.
Damn! I wonder if, despite it being an “intended“ feature, GitHub will pivot to changing the way this behaves now that it’s being publicized (and publicly critized).