Organizations and personal forking for inner source?

I’m trying to improve our GitHub organization setup to enable an inner source approach. Although the repositories aiming for inner source collaboration are already ‘internal’ we still prefer to have a policy in place to prevent changes on the default branches you would typically protect. One way of going about this is to hand out ‘write’ access to all organization members and have protected branches in place. GitHub currently doesn’t support setting protected branches by default, so this quickly becomes a hassle to manage, requiring bots or alike.

Another way of working I could think of are personal forks. If you want to contribute you can create a personal fork and open a pull-request. Just as you would do for a public project. But what guarantees are in place for code security with personal forks from organization repositories? Will personal forks be deleted if a GitHub user is removed from the organization? Can personal forks allow outside collaborators even if the repository from the organization doesn’t? Knowing that forks are deleted if the main repository is deleted, I have the impression that security matters are quite good. Yet personal forking is disabled for organizations by default, which I find quite odd. It would seem the best way of work I could think of.

I hope somebody can ensure me that personal forks do not open a back door for code to escape the GitHub organization.

Hi @nicorikken, taking your questions
Will personal forks be deleted if a GitHub user is removed from the organization? Yes, If you remove a person’s access to a private repository, any of their forks of that private repository are deleted. Local clones of the private repository are retained. If a team’s access to a private repository is revoked or a team with access to a private repository is deleted, and team members do not have access to the repository through another team, private forks of the repository will be deleted.

Can personal forks allow outside collaborators even if the repository from the organization doesn’t?
Yes, I was able to invite an outside collaborator to my forked repository who was not a member of the parent organization repository.

There are some other controls like preventing changing a the fork to public if the parent repository is private and also transfer ownership.

Its not perfect…

Having said all the above a user with access to a private/internal repository can simply duplicate by creating a new repository from the contents of an existing repository. GitHub in this case has no relationship to the duplicated repository and cannot and does not apply any additional controls to a user duplicated repository. This risk exists regardless of whether forking is enabled or not.

Some of the behaviour is described at this link what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility

1 Like

Thank you very much @byrneh ! This is what I was expecting and I’m happy for it. This would allow personal forking as a way of work for code within an organization. In that regard I don’t understand why forking is disabled by default.

I missed that page in the documentation, so thanks for linking it.

The outside collaborators issue is something I would like to know in greater detail. The risk might be manageable. I found this page in the documentation, but it doesn’t cover if the permissions or limitations get passed on to the forked repository.

Indeed the GitHub link for a fork can be bypassed by creating a new repository from the code. But like you mention this risk exists the moment one could clone the repository. This risk is not changed by changing the forking policy.

I have not tested whether this is inherited by the forked repository either, as whilst the setting was enabled on my organization, I was the organization owner when I tested the forked repository functionality.

1 Like