3 ms·

If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access

by shagie 4y ago

If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access to the repos removed? or an email that says that it will be removed?

amelius 4y ago
I'd prefer it if the repo was returned to the company, rather than removed.
- shagie 4y ago
  That gets complicated. It's in (for example) my namespace. So shagie/foo.git And now you want to return it to BigOrg/foo.git - where does it go in that namespace of BigOrg? What are the permissions for who should have access to that? Who gets billed with a scheduled action runs and chews up a lot of CI credits as a parting gift? The workflows for anything other than "delete it" gets GitHub in a bit of a mess.
kitkat_new 4y ago
one of many scenarios in which it is probably(!) desirable to revoke access. What about other scenarios?
xigoi 4y ago
What prevents them from having the code locally?
- shagie 4y ago
  Same nothing that prevents a person from copying it onto a USB stick before they leave. However, that's not GitHub's problem. GitHub is "told" (by removing the person's access from the repo) that they shouldn't have access to the repository or its code. It is within GitHub's ability to remove access to their fork and remove it.
- filoleg 4y ago
  > What prevents them from having the code locally? Likely lack of initial intent and effort. Just like having firewalls and the most recent security updates doesn't mean that you are inpenetrable. After all, the most common attack vector is the good old phishing email tactics and other ways of social engineering someone anyway. However, it doesn't mean that you shouldn't have a firewall (or other ways of defending your server) or that you should neglect timely security updates. There are layers to this. Sure, someone who had an intent to do it from the start could've cloned the repo locally ahead of time. But for a lot of people it could be a crime of opportunity. Or it could also be that their account with access to the fork on github gets compromised later and a malicious third party got access to it. My point is, having this restriction on forks won't prevent a determined attacker from getting it preserved locally ahead of time, you are correct. But it will prevent a lot of other unwanted scenarios that could result from not having the current restriction on forks of repos that went private.
dpkirchner 4y ago
> had a fork of a private repo This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork. It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).
- shagie 4y ago
  That gets into other aspects of how people are using GitHub. Using that model, your work on private repos wouldn't show up as "your" GitHub activity history. Your work on external projects sanctioned by your employer (and thus using your employer's managed account) wouldn't be associated with you when you leave. For example, if you were at VMWare and contributed to the Spring project - if you left VMWare the "I did core work on Spring - its right there in a public repo" would not be associated with the account that you're saying is you. Yes, it is weird to be mixing work accounts and personal accounts (and the mess I have had with email when my gmail account was associated with a former employer). There's tradeoffs no matter which way that you do this... and people appear to prefer the set of "using a single account on GitHub for work and personal" and then having the follow on implications of that being that you may lose access to internal repos when you leave... which you would in either case, just its a bit more surprising when its your "personal" account.
- alerighi 4y ago
  Yes, because GitHub doesn't support organization users (maybe you have to pay?) so the thing is that you use your personal account. That is fine, since the real account is the membership to the organization. The only thing is the stuff of private repo: if there is this unintuitive behaviour it shouldn't be allowed to fork private repositories at all. Or the fork should not be deleted, but it should be made in a way that it's equivalent to a pull and then push to another repo, that is if you loose access to the original private repo you can still see your code, but you can no longer pull from the upstream private repo. I think this is a problem on how data/permissions is represented at low level in a repo, so if this is the case and cannot be fixed they shouldn't allow private repo fork at all.

by shagie 4y ago

amelius 4y ago

I'd prefer it if the repo was returned to the company, rather than removed.

shagie 4y ago
That gets complicated. It's in (for example) my namespace. So shagie/foo.git And now you want to return it to BigOrg/foo.git - where does it go in that namespace of BigOrg? What are the permissions for who should have access to that? Who gets billed with a scheduled action runs and chews up a lot of CI credits as a parting gift? The workflows for anything other than "delete it" gets GitHub in a bit of a mess.

kitkat_new 4y ago

one of many scenarios in which it is probably(!) desirable to revoke access. What about other scenarios?

xigoi 4y ago

What prevents them from having the code locally?

shagie 4y ago
Same nothing that prevents a person from copying it onto a USB stick before they leave. However, that's not GitHub's problem. GitHub is "told" (by removing the person's access from the repo) that they shouldn't have access to the repository or its code. It is within GitHub's ability to remove access to their fork and remove it.
filoleg 4y ago
> What prevents them from having the code locally? Likely lack of initial intent and effort. Just like having firewalls and the most recent security updates doesn't mean that you are inpenetrable. After all, the most common attack vector is the good old phishing email tactics and other ways of social engineering someone anyway. However, it doesn't mean that you shouldn't have a firewall (or other ways of defending your server) or that you should neglect timely security updates. There are layers to this. Sure, someone who had an intent to do it from the start could've cloned the repo locally ahead of time. But for a lot of people it could be a crime of opportunity. Or it could also be that their account with access to the fork on github gets compromised later and a malicious third party got access to it. My point is, having this restriction on forks won't prevent a determined attacker from getting it preserved locally ahead of time, you are correct. But it will prevent a lot of other unwanted scenarios that could result from not having the current restriction on forks of repos that went private.

dpkirchner 4y ago

> had a fork of a private repo This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork. It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).

shagie 4y ago
That gets into other aspects of how people are using GitHub. Using that model, your work on private repos wouldn't show up as "your" GitHub activity history. Your work on external projects sanctioned by your employer (and thus using your employer's managed account) wouldn't be associated with you when you leave. For example, if you were at VMWare and contributed to the Spring project - if you left VMWare the "I did core work on Spring - its right there in a public repo" would not be associated with the account that you're saying is you. Yes, it is weird to be mixing work accounts and personal accounts (and the mess I have had with email when my gmail account was associated with a former employer). There's tradeoffs no matter which way that you do this... and people appear to prefer the set of "using a single account on GitHub for work and personal" and then having the follow on implications of that being that you may lose access to internal repos when you leave... which you would in either case, just its a bit more surprising when its your "personal" account.
alerighi 4y ago
Yes, because GitHub doesn't support organization users (maybe you have to pay?) so the thing is that you use your personal account. That is fine, since the real account is the membership to the organization. The only thing is the stuff of private repo: if there is this unintuitive behaviour it shouldn't be allowed to fork private repositories at all. Or the fork should not be deleted, but it should be made in a way that it's equivalent to a pull and then push to another repo, that is if you loose access to the original private repo you can still see your code, but you can no longer pull from the upstream private repo. I think this is a problem on how data/permissions is represented at low level in a repo, so if this is the case and cannot be fixed they shouldn't allow private repo fork at all.