7 ms·

As someone who runs a bunch of private repos on Github, and hires freelancers and vendors to work on them, I like the way Github manages forks of private repos.

As someone who runs a bunch of private repos on Github, and hires freelancers and vendors to work on them, I like the way Github manages forks of private repos. When I end a relationship, and remove that person from my private repo, I want their fork of my code to go away too. Why? Because it's cleaner. It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts. I set up a private repo because I want to control access to my code. That's why a private repo is private. It also makes it harder for people to misrepresent their relationship to me later on. Sure, anyone with read access to one of my repos can pull it down and save a local copy. But that is different from logging into Github and having a fork of my repo. A Github fork looks and works differently from a local copy. This whole situation seems weird because the idea of a "private" repo is not inherent to how git was intended to work; it's something Github invented to make money. So I'm not surprised that it violates people's expectations sometimes.

fwdpropaganda 9y ago
That makes no sense to me. You're relying on people not making their forks out of github. If that strategy works at all, it's incidental and I wouldn't rely on it for anything that matters.
- sdrothrock 9y ago
  > You're relying on people not making their forks out of github. That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
  - fwdpropaganda 9y ago
    > That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code." No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account. So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. In fact if you don't believe me give me access to your private repos and lets see what happens.
    - inetknght 9y ago
      I would be willing to bet that it would be fairly trivial for Github to identify fraudulent repos like that.
    - CoryG89 9y ago
      While yes, you can simply create a new repo on GitHub with the local copy and name it similarly, it will not be linked to the original as a fork on GitHub.
    - function_seven 9y ago
      You're misunderstanding the intent I think. This isn't a guarantee that the code is kept private. It's a guarantee that the other copies don't have a Github "fork" relationship to the true repo. Nobody is disputing that access to the private repo allows for a copy to be kept. But it's an "island", not a fork.
    - monsieurbanana 9y ago
      > So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. Come on, no one is arguing that, and I'm sure you know that. He said it's "cleaner", not more secure. Yes anybody can re-upload his code to a random github account, but then it's easier to see it's stolen code in contrast of having a github fork of the private repository.
    - s73v3r_ 9y ago
      "So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts" Nobody but you is claiming this.
      - fwdpropaganda 9y ago
        Me and the person I was responding to. > It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts.
  - BlackLotus89 9y ago
    The op doesn't want the code to be on github and his problem was about his code still being on someone elses accoint as a private fork. It sounded more like "if they get hacked my code isn't there" Being legit doesn't seem to have any meaning for him or the author of the article. Also the code is the only thing needed for legitimacy. The iphone bootloader code in some repo is still the legit iphone bootloader (as an example)
  - ctrl-j 9y ago
    But they can still download the source and re-upload it to GitHub. It's really a false sense of control.
    - moondev 9y ago
      But it won't say "forked from..."
      - gkya 9y ago
        And how does it matter when it's a private repo?
        moondev 9y ago
        Imagine you run a website, foobar.com. You have foobar.com github org and foobar private repo (and also some public ones). Its the canonical org/repo. ninja123 has a github fork of it and it relays that from the github ui. "forked from foobar/foobar.com". rockstar123 also has a "fork" but it's just code sitting out there at rockstar123/foobar.com. There is no link to the canonical repo. If you fire ninja123 the link is severed. It just allows a way to show active, approved engagement and also to keep track of approved collaborators. What if rockstar123 gets arrested for ICO fraud. Do you want others to see he has an official upstream link to your repo even after you have severed the relationship? What if rockstar123 makes his fork public? It's just messy to keep the link.
        gkya 9y ago
        I do not want to believe Github allows to make a privately-forked repository public. Other than that, I agree that the link is better removed, but what I don't understand is how that helps with keeping the code itself private, which is what I thought was meant at the root of the thread.
        moondev 9y ago
        Op is not claiming it keeps it private. It's just used as a tool to signal and track approved, active collaborators to the official upstream. That's beneficial to control.
- snowwrestler 9y ago
  > You're relying on people not making their forks out of github. I'm not. Did you read my 3rd paragraph? This is not a security strategy, it is a strategy for managing relationships--which is the purpose of using Github in the first place. There are far more secure ways to manage a git repo than Github, if that is the goal.
  - gkya 9y ago
    > it is a strategy for managing relationships Not really. That means that you've worked with benevolent actors up until now. It's not that hard to keep a clone of the repo and upload later after the termination of the business rapport, either as a private or a public one.
    - Klathmon 9y ago
      But unless you are giving your contractors a locked-down internet-disconnected laptop and physically locking them in an empty room, you need to trust that they aren't going to steal your code like that anyway.
      - fwdpropaganda 9y ago
        So you agree that github mechanics doesn't prevent code theft.
        Klathmon 9y ago
        Yes, and nobody is disputing that.
        jsight 9y ago
        I think he was very clear that his approach had nothing to do with the security of the actual code.
      - gkya 9y ago
        Certainly. I---and some others, seemingly---was just saying that what Github does is not that much of an help (which is what seems to be meant at the thread root). The keyword is contractor here, as it should be the contract that protects you from theft &c. Though I'm not much knowledgeable about business, so maybe I'm failing to see how that's useful.
- marcosdumay 9y ago
  It is a way of avoiding that all too common situation: - collaborator get a copy of your code, works a bit on it; - collaboration stops; - a few months pass and you start collaborating with the same person again; - collaborator then pushes some changes based on outdated information and breaks everything
  - conta 9y ago
    > collaborator then pushes some changes based on outdated information and breaks everything github does have better ways to prevent that. that's the point of using git, right?
secstate 9y ago
But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. You merely have the appearance of cleanliness with none of the security. The only way to really protect yourself is with a contract that stipulates the repo and any clones a contractor may have access to must be destroyed upon termination of the contract.
- sevensor 9y ago
  For that matter, what's stopping them from pushing a clone to Github instead of forking through Github's web interface?
- snowwrestler 9y ago
  This has nothing to do with security. Would you upload secrets into a private Github repo? I wouldn't. Private repos are not more secure than public repos. Github is a tool for collaboration. The point of a private repo is to manage who you are collaborating with. Once I don't want to collaborate with someone anymore, there is no reason for them to have a Github fork of my code anymore. As I said, it's cleaner. I'm fully aware that they can save a local copy (did you read my 3rd paragraph above?), and of the importance of contracts.
  - andrewstuart2 9y ago
    Access control is 100% security. If you have a private GitHub repo, you have uploaded secrets. All that code is your secret. You pay GitHub to protect all the copies they know about, but you are fooling yourself if you rely on that after you've given access to that private repo away. You fundamentally can't revoke knowledge, just future access.
    - snowwrestler 9y ago
      No, secrets are pieces of information that you could use to compromise my production environment--like passwords or private keys. Those should never be uploaded to Github, period.
masklinn 9y ago
An other solution would be to create an org, give access to people you want as collaborators and forbid forking. They can work in branches in the main repository, and you can use protected branches to alleviate the risk of incorrect pushes.
- ISL 9y ago
  When they clone to the machine on which they're going to work, they get a copy of the repo. That's part of the point of git. Git, by design, is a platform for the sharing of managed text.
  - moondev 9y ago
    But there is no github.com upstream relationship. Sure they can upload it, but it will be obvious it's rogue copy since there is no "forked from.." messaging to the canonical repo.
jeremiep 9y ago
That's naive wishful thinking at best. The cons far outweighs the pros on this feature. They're one button away from cloning the entire repo out of Github and bypassing all these fancy access control mechanisms without you even knowing about it. This is one feature that causes a lot more pain than actual utility.
- snowwrestler 9y ago
  It doesn't cause pain for my contractors because a) they know how Github private repos work, and b) they don't want a copy of my code in their Github account once our relationship has ended. Killing forks upon removal makes life easier for everyone.
nebulous1 9y ago
I don't have any particular issue with the way that Github do this, but you're exaggerating the effect of the github hosted fork. Somebody using a private fork to misrepresent their relationship to you seems like a stretch, as all it shows is that you gave them access to your repo, which you in fact did do. Also, not only "could" they clone a local copy, they almost certainly have done so as that's how 99% of work flows go. Also, git does inherently allow for private repos, otherwise it would have been licenced differently, and it inherently allows for access control (ie repos don't have to be readable without authentication). Like I said though, github's stance of disabling a private fork of a private repo when the permission is revoked doesn't seem unreasonable to me. I think the key thought missed by the OP was that they were both private repos. Also, they could deal with it differently when it's non-payment that caused the shutdown rather than a deletion/revoked permission
BlackLotus89 9y ago
> But that is different from logging into Github and having a fork of my repo. How is it really different? When you push it back up to github it is exactly as if you'd have forked it. The only difference is that it isn't marked as a fork and in this respect not shown when you look at the original repo graph. It's nice that it works for your usecase, but since it's not a real protection against anything and only looks like a safety measure against abondend accounts that still have a copy of your code, it shouldn't be a feature that's on by default. (Imho)
- moondev 9y ago
  > The only difference is that it isn't marked as a fork and in this respect not shown when you look at the original repo graph. Thats the whole point. Of course you can't stop someone from pushing a repo anywhere they want. But imagine you run a website, foobar.com. You have foobar.com github org and foobar private repo. Its the canonical repo. ninja123 has a github fork of it and it relays that from the github ui. "forked from foobar/foobar.com". rockstar123 also has a "fork" but it's just code sitting out there at rockstar123/foobar.com. There is no link to the canonical repo. If you fire rockstar123 the link is severed. It just allows a way to show active, approved engagement and also to keep track of approved collaborators. What if rockstar123 gets arrested for ICO fraud. Do you want others to see he has an official upstream link to your repo even after you have severed the relationship?
  - recursive 9y ago
    I don't think the existence of a "github fork" shows any active approval. The default behavior for repos is to allow anyone to fork them without requesting approval.
boomlinde 9y ago
What you're looking for is perhaps not a decentralized version control system.
- snowwrestler 9y ago
  While git is a decentralized version control system, I would argue that using Github is not really decentralized. Even when everyone has a full local copy to work on, the norm is for everyone to set the Github repo as the remote origin and push/pull from there, rather than from each other. This is in contrast to how the Linux kernel development works, for instance.
  - boomlinde 9y ago
    Decentralized doesn't necessarily mean peer to peer. In the case of git, it simply means users work with a local repository that can easily be synchronized with another repository. A team contributing to the kernel could very well use github to do so, change their mind and switch their remote to bitbucket and continue the work there. If bitbucket exploded, they could set up their own remote, push any of the local copies and use that. If their internet connections exploded they could print patches and mail them to each other. Then when they're back online and done with their change, they can create a patch file and mail that to Torvalds. But that's all besides the point. The point is that if you don't want your code laying around where you have no control over it and don't trust your contract and the law to be enough of a deterrent, you shouldn't give people copies of it and probably reconsider what kind of contractor you're willing to work with, rather than loading the term "fork" with an additional meaning.
    - diggan 9y ago
      I mean, you could even do git peer-to-peer via ssh. Each person sets up sshd and a bare git repository, add it to their remote and now they can push to each others "ssh" repositories and then fetch from it when wanted.
      - boomlinde 9y ago
norswap 9y ago
Why not allow both mechanisms? Real forks and shadow forks that will become disabled when the parent becomes disabled?
darklajid 9y ago
I think a lot of people don't understand your "I want no link on GitHub" argument and try to explain that you can't keep the code. I'm coming from a different angle. I read the article as "wasn't able to access his fork anymore". If that is true, I think that is bullshit. Severing the ties to the private repo? Fine, I get the (your?) point. But what I forked should still be there. Previously as "forked from...", now without the link? Did I misunderstand the article?
bryanrasmussen 9y ago
The explicit problem here though is not that the friend disabled the repo and all forks of the private repo got disabled, it't that github disabled the friend's private repo and this caused forks to be disabled. First one understandable, I fork a private repo I can't expect it to stay forked if for some reason person who owns it doesn't want me to. Second one is screw github.
- deleted 9y ago
  [deleted]

fwdpropaganda 9y ago

That makes no sense to me. You're relying on people not making their forks out of github. If that strategy works at all, it's incidental and I wouldn't rely on it for anything that matters.

sdrothrock 9y ago
> You're relying on people not making their forks out of github. That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
- fwdpropaganda 9y ago
  > That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code." No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account. So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. In fact if you don't believe me give me access to your private repos and lets see what happens.
  - inetknght 9y ago
    I would be willing to bet that it would be fairly trivial for Github to identify fraudulent repos like that.
  - CoryG89 9y ago
    While yes, you can simply create a new repo on GitHub with the local copy and name it similarly, it will not be linked to the original as a fork on GitHub.
  - function_seven 9y ago
    You're misunderstanding the intent I think. This isn't a guarantee that the code is kept private. It's a guarantee that the other copies don't have a Github "fork" relationship to the true repo. Nobody is disputing that access to the private repo allows for a copy to be kept. But it's an "island", not a fork.
  - monsieurbanana 9y ago
    > So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. Come on, no one is arguing that, and I'm sure you know that. He said it's "cleaner", not more secure. Yes anybody can re-upload his code to a random github account, but then it's easier to see it's stolen code in contrast of having a github fork of the private repository.
  - s73v3r_ 9y ago
    "So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts" Nobody but you is claiming this.
    - fwdpropaganda 9y ago
      Me and the person I was responding to. > It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts.
- BlackLotus89 9y ago
  The op doesn't want the code to be on github and his problem was about his code still being on someone elses accoint as a private fork. It sounded more like "if they get hacked my code isn't there" Being legit doesn't seem to have any meaning for him or the author of the article. Also the code is the only thing needed for legitimacy. The iphone bootloader code in some repo is still the legit iphone bootloader (as an example)
- ctrl-j 9y ago
  But they can still download the source and re-upload it to GitHub. It's really a false sense of control.
  - moondev 9y ago
    But it won't say "forked from..."
    - gkya 9y ago
      And how does it matter when it's a private repo?
      - moondev 9y ago
        Imagine you run a website, foobar.com. You have foobar.com github org and foobar private repo (and also some public ones). Its the canonical org/repo. ninja123 has a github fork of it and it relays that from the github ui. "forked from foobar/foobar.com". rockstar123 also has a "fork" but it's just code sitting out there at rockstar123/foobar.com. There is no link to the canonical repo. If you fire ninja123 the link is severed. It just allows a way to show active, approved engagement and also to keep track of approved collaborators. What if rockstar123 gets arrested for ICO fraud. Do you want others to see he has an official upstream link to your repo even after you have severed the relationship? What if rockstar123 makes his fork public? It's just messy to keep the link.
        gkya 9y ago
        I do not want to believe Github allows to make a privately-forked repository public. Other than that, I agree that the link is better removed, but what I don't understand is how that helps with keeping the code itself private, which is what I thought was meant at the root of the thread.
        moondev 9y ago
        Op is not claiming it keeps it private. It's just used as a tool to signal and track approved, active collaborators to the official upstream. That's beneficial to control.
snowwrestler 9y ago
> You're relying on people not making their forks out of github. I'm not. Did you read my 3rd paragraph? This is not a security strategy, it is a strategy for managing relationships--which is the purpose of using Github in the first place. There are far more secure ways to manage a git repo than Github, if that is the goal.
- gkya 9y ago
  > it is a strategy for managing relationships Not really. That means that you've worked with benevolent actors up until now. It's not that hard to keep a clone of the repo and upload later after the termination of the business rapport, either as a private or a public one.
  - Klathmon 9y ago
    But unless you are giving your contractors a locked-down internet-disconnected laptop and physically locking them in an empty room, you need to trust that they aren't going to steal your code like that anyway.
    - fwdpropaganda 9y ago
      So you agree that github mechanics doesn't prevent code theft.
      - Klathmon 9y ago
        Yes, and nobody is disputing that.
      - jsight 9y ago
        I think he was very clear that his approach had nothing to do with the security of the actual code.
    - gkya 9y ago
      Certainly. I---and some others, seemingly---was just saying that what Github does is not that much of an help (which is what seems to be meant at the thread root). The keyword is contractor here, as it should be the contract that protects you from theft &c. Though I'm not much knowledgeable about business, so maybe I'm failing to see how that's useful.
marcosdumay 9y ago
It is a way of avoiding that all too common situation: - collaborator get a copy of your code, works a bit on it; - collaboration stops; - a few months pass and you start collaborating with the same person again; - collaborator then pushes some changes based on outdated information and breaks everything
- conta 9y ago
  > collaborator then pushes some changes based on outdated information and breaks everything github does have better ways to prevent that. that's the point of using git, right?

secstate 9y ago

But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. You merely have the appearance of cleanliness with none of the security. The only way to really protect yourself is with a contract that stipulates the repo and any clones a contractor may have access to must be destroyed upon termination of the contract.

sevensor 9y ago
For that matter, what's stopping them from pushing a clone to Github instead of forking through Github's web interface?
snowwrestler 9y ago
This has nothing to do with security. Would you upload secrets into a private Github repo? I wouldn't. Private repos are not more secure than public repos. Github is a tool for collaboration. The point of a private repo is to manage who you are collaborating with. Once I don't want to collaborate with someone anymore, there is no reason for them to have a Github fork of my code anymore. As I said, it's cleaner. I'm fully aware that they can save a local copy (did you read my 3rd paragraph above?), and of the importance of contracts.
- andrewstuart2 9y ago
  Access control is 100% security. If you have a private GitHub repo, you have uploaded secrets. All that code is your secret. You pay GitHub to protect all the copies they know about, but you are fooling yourself if you rely on that after you've given access to that private repo away. You fundamentally can't revoke knowledge, just future access.
  - snowwrestler 9y ago
    No, secrets are pieces of information that you could use to compromise my production environment--like passwords or private keys. Those should never be uploaded to Github, period.

masklinn 9y ago

An other solution would be to create an org, give access to people you want as collaborators and forbid forking. They can work in branches in the main repository, and you can use protected branches to alleviate the risk of incorrect pushes.

ISL 9y ago
When they clone to the machine on which they're going to work, they get a copy of the repo. That's part of the point of git. Git, by design, is a platform for the sharing of managed text.
- moondev 9y ago
  But there is no github.com upstream relationship. Sure they can upload it, but it will be obvious it's rogue copy since there is no "forked from.." messaging to the canonical repo.

jeremiep 9y ago

That's naive wishful thinking at best. The cons far outweighs the pros on this feature. They're one button away from cloning the entire repo out of Github and bypassing all these fancy access control mechanisms without you even knowing about it. This is one feature that causes a lot more pain than actual utility.

snowwrestler 9y ago
It doesn't cause pain for my contractors because a) they know how Github private repos work, and b) they don't want a copy of my code in their Github account once our relationship has ended. Killing forks upon removal makes life easier for everyone.

nebulous1 9y ago

I don't have any particular issue with the way that Github do this, but you're exaggerating the effect of the github hosted fork. Somebody using a private fork to misrepresent their relationship to you seems like a stretch, as all it shows is that you gave them access to your repo, which you in fact did do. Also, not only "could" they clone a local copy, they almost certainly have done so as that's how 99% of work flows go. Also, git does inherently allow for private repos, otherwise it would have been licenced differently, and it inherently allows for access control (ie repos don't have to be readable without authentication). Like I said though, github's stance of disabling a private fork of a private repo when the permission is revoked doesn't seem unreasonable to me. I think the key thought missed by the OP was that they were both private repos. Also, they could deal with it differently when it's non-payment that caused the shutdown rather than a deletion/revoked permission

BlackLotus89 9y ago

> But that is different from logging into Github and having a fork of my repo. How is it really different? When you push it back up to github it is exactly as if you'd have forked it. The only difference is that it isn't marked as a fork and in this respect not shown when you look at the original repo graph. It's nice that it works for your usecase, but since it's not a real protection against anything and only looks like a safety measure against abondend accounts that still have a copy of your code, it shouldn't be a feature that's on by default. (Imho)

moondev 9y ago
> The only difference is that it isn't marked as a fork and in this respect not shown when you look at the original repo graph. Thats the whole point. Of course you can't stop someone from pushing a repo anywhere they want. But imagine you run a website, foobar.com. You have foobar.com github org and foobar private repo. Its the canonical repo. ninja123 has a github fork of it and it relays that from the github ui. "forked from foobar/foobar.com". rockstar123 also has a "fork" but it's just code sitting out there at rockstar123/foobar.com. There is no link to the canonical repo. If you fire rockstar123 the link is severed. It just allows a way to show active, approved engagement and also to keep track of approved collaborators. What if rockstar123 gets arrested for ICO fraud. Do you want others to see he has an official upstream link to your repo even after you have severed the relationship?
- recursive 9y ago
  I don't think the existence of a "github fork" shows any active approval. The default behavior for repos is to allow anyone to fork them without requesting approval.

boomlinde 9y ago

What you're looking for is perhaps not a decentralized version control system.

snowwrestler 9y ago
While git is a decentralized version control system, I would argue that using Github is not really decentralized. Even when everyone has a full local copy to work on, the norm is for everyone to set the Github repo as the remote origin and push/pull from there, rather than from each other. This is in contrast to how the Linux kernel development works, for instance.
- boomlinde 9y ago
  Decentralized doesn't necessarily mean peer to peer. In the case of git, it simply means users work with a local repository that can easily be synchronized with another repository. A team contributing to the kernel could very well use github to do so, change their mind and switch their remote to bitbucket and continue the work there. If bitbucket exploded, they could set up their own remote, push any of the local copies and use that. If their internet connections exploded they could print patches and mail them to each other. Then when they're back online and done with their change, they can create a patch file and mail that to Torvalds. But that's all besides the point. The point is that if you don't want your code laying around where you have no control over it and don't trust your contract and the law to be enough of a deterrent, you shouldn't give people copies of it and probably reconsider what kind of contractor you're willing to work with, rather than loading the term "fork" with an additional meaning.
  - diggan 9y ago
    I mean, you could even do git peer-to-peer via ssh. Each person sets up sshd and a bare git repository, add it to their remote and now they can push to each others "ssh" repositories and then fetch from it when wanted.
    - boomlinde 9y ago

norswap 9y ago

Why not allow both mechanisms? Real forks and shadow forks that will become disabled when the parent becomes disabled?

darklajid 9y ago

I think a lot of people don't understand your "I want no link on GitHub" argument and try to explain that you can't keep the code. I'm coming from a different angle. I read the article as "wasn't able to access his fork anymore". If that is true, I think that is bullshit. Severing the ties to the private repo? Fine, I get the (your?) point. But what I forked should still be there. Previously as "forked from...", now without the link? Did I misunderstand the article?

bryanrasmussen 9y ago

The explicit problem here though is not that the friend disabled the repo and all forks of the private repo got disabled, it't that github disabled the friend's private repo and this caused forks to be disabled. First one understandable, I fork a private repo I can't expect it to stay forked if for some reason person who owns it doesn't want me to. Second one is screw github.

deleted 9y ago
[deleted]