Tell HN: GitHub will delete your private repo if you lose access to the original • Hacker News Board

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#101

Post by pavon » Tue, Jan 31, 2023, 10:41 PM UTC

Mystery-Machine wrote: post #57

gregwebs wrote: post #33

This unfortunately makes sense because it is a private repo. Even if a repo is labeled as being MIT and has an MIT license in it, it still may contain other code of a different license. Github could do better by warning the repo owner when they delete a private repo. Github could ask the repo owner if they want to convert it to public first (a "set it free" option) or otherwise give the option to avoid deleting the f…

GitHub is not supposed to make such decisions for the user here. It is user's responsibility to make sure they delete their private forks if they shouldn't have access to the repo/fork anymore. What's next? Should we all install spyware on our computers and let GitHub automatically delete local copies of forks as well? GitHub and the company/person, who deleted the original private repo, should inform the owner of th…

I think this incident reinforces that private repos on github.com are a weird hybrid of the public github and on-premise github which creates various practical problems and misunderstandings when those two security models collide.

First off is the fact that forking a repo is often a necessary step in contributing to project if you don't have push permission, so these forks will be created during the normal development processes, not necessarily because the employee was intentionally trying to save off their own copy. So it is perfectly normal for the employer to consider those forks to be something it should own and manage, just like it would on an on-premise installation.

On the otherhand, github still encourages people to use a single account for both personal use and work[1]. Naturally the employees reasonably consider all the forks that are in their personal account to be something that they should own and manage. So you end up with situtations like this.

The lesson - mixing work and personal accounts/computers/devices is a horrible idea regardless of what Github says. Employers shouldn't allow it, and employees should avoid it even if allowed. Then both will have a clear idea of who owns and controls what.

[1] https://docs.github.com/en/get-started/learning-about-github...

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#102

Post by chrisfosterelli » Tue, Jan 31, 2023, 10:42 PM UTC

capableweb wrote: post #93

chrisfosterelli wrote: post #39

Earlier quoted context omitted.

I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's…

> I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. This is exactly how it works today already. If I try to delete a private repository people have forked, I see the following: > We will also…

Yes, that's what I said. It sounds like the parent poster is suggesting that the fork account should instead have that notice.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#103

Post by dreamcompiler » Tue, Jan 31, 2023, 10:46 PM UTC

bcrosby95 wrote: post #80

kitkat_new wrote: post #46

Earlier quoted context omitted.

"This unfortunately makes sense because it is a private repo." I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if it is private or not. It's enough if a fork of a private repository is private then too.

This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.

This is the right answer: Break the fork link. I sometimes do this to make a private "fork" of a public repo so that I can add my own notes about how to use it, remind myself what happened when I tried it, add a config script for my own peculiar setup, etc.

It's unfortunate because not having a "real" fork makes it harder to send pull requests and track the upstream. But it's sometimes necessary to get around stupid github policies.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#104

Post by edaemon » Tue, Jan 31, 2023, 10:47 PM UTC

ntrz wrote: post #89

bcrosby95 wrote: post #80

Earlier quoted context omitted.

This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.

Don't you need to have an "GitHub-approved" fork (i.e. use the GitHub fork button) if you want to create pull requests on the upstream project in GitHub? Or is there a way to do that from the kind of repo you're describing?

If that came up you could create a GitHub-native fork and add that as a remote.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#105

Post by autophagian » Tue, Jan 31, 2023, 10:58 PM UTC

capableweb wrote: post #96

pvaldes wrote: post #83

Totally expected from the minute one after Microsoft buy the vault, earning full control over the software and the people's access to the platform. I will not be surprised at all if some of this closed projects would appear included into closed software under new authors after a year.

Is this behavior new? It has been like that for as long as I can remember, certainly before Microsoft bought GitHub.

It is not. I also remember this behavior around forking private repos from before the acquisition. But then again, this doesn't lend itself to a conveniently pithy comment about Microsoft ruining everything.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#106

Post by jiggawatts » Tue, Jan 31, 2023, 10:59 PM UTC

tux3 wrote: post #7

I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.

Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way.

If a Microsoft IC leaves, they should lose access to all Git repos, including forks.

If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped.

But Microsoft has One Rule To Rule Them All, so they won't make exceptions for unimportant people like their customers.

I see this a lot. A good example is Azure Active Directory, which is basically "Microsoft 365 Authentication" that they rebranded and sold to developers for their own use, i.e.: Azure AD Enterprise Apps, App Registrations, and B2C.

There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365!

For example, auditing. My customers are typically government agencies or banks, and they have strict auditing requirements, especially related to data access. All user authentication MUST be logged, including client IP address, and everything else. Most access is by their own staff, or by other orgs that have signed various contracts or agreements, so there is no expectation of privacy.

This is basically impossible with many configurations of AAD. It just refuses to collect meaningful audit logs. Why? Because GDPR applies to Microsoft 365 and they don't care about the data hosted on services such as SharePoint Online. That's not Microsoft's data, that's their customers' data, so its up to the customers to enable logging "on their end", in their individual AAD tenants.

There is no way to centrally collect logs as a service provider using AAD in a multi-tenant scenario.

When I asked Microsoft about this, they waffled on about GDPR and privacy regulations -- which apply to them, but not us.

Another example is Microsoft Teams, which hides the name of the organisation people are coming from. In large multi-org meetings this is infuriating, because you have no idea where anyone is from. Microsoft does this because they use outsourcers like MindTree for support, and they don't want their customers to see this in Teams meetings for Azure support tickets. No-one is allowed to see where people are from so that Microsoft can bullshit their customers.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#107

Post by evouga » Tue, Jan 31, 2023, 10:59 PM UTC

tux3 wrote: post #7

I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.

This doesn’t make any sense to me.

My private forks are *mine* and I most certainly do not want GitHub guessing at whether and when to permanently delete them without my consent.

Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#108

Post by westurner » Tue, Jan 31, 2023, 11:00 PM UTC

josephg wrote: post #99

capableweb wrote: post #90

Earlier quoted context omitted.

Yeah, better in terms of saving space, but I think it confuses some people, hence I didn't use it in my above example. Previous time I recommended a co-worker to use the `push to a directory` way of copying a git repository, I made them create a bare repository, and they ended up going into the directory to verify it worked and not seeing what they expected. Cue me having to explain the difference between a normal re…

I hear all that, but --bare is necessary in this case because git (by default) won't let you push to a non-bare filesystem branch: ~/temp/a:master $ git push backup Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: error: refusing to update checked out branch: refs/heads/master rem…

  git clone --mirror
  git clone --bare
  git push --mirror
  git push --all

"Is `git push --mirror` sufficient for backing up my repository?" https://stackoverflow.com/questions/3333102/is-git-push-mirr... :

> So it's usually best to use --mirror for one time copies, and just use normal push (maybe with --all) for normal uses.

git push: https://git-scm.com/docs/git-push

git clone: https://git-scm.com/docs/git-clone

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#109

Post by s17n » Tue, Jan 31, 2023, 11:01 PM UTC

Same thing happened to me, it sucks. All the development had been in my fork (not just my own work, also my collaborators;) and now it's just gone.

Github should change this policy.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#110

Post by jyrkesh » Tue, Jan 31, 2023, 11:04 PM UTC

Mystery-Machine wrote: post #57

gregwebs wrote: post #33

This unfortunately makes sense because it is a private repo. Even if a repo is labeled as being MIT and has an MIT license in it, it still may contain other code of a different license. Github could do better by warning the repo owner when they delete a private repo. Github could ask the repo owner if they want to convert it to public first (a "set it free" option) or otherwise give the option to avoid deleting the f…

GitHub is not supposed to make such decisions for the user here. It is user's responsibility to make sure they delete their private forks if they shouldn't have access to the repo/fork anymore. What's next? Should we all install spyware on our computers and let GitHub automatically delete local copies of forks as well? GitHub and the company/person, who deleted the original private repo, should inform the owner of th…

MIT licensed code doesn't mandate distribution. Companies and organizations are perfectly within their rights to own a private fork of an MIT-licensed codebase in perpetuity.

With that in mind, if you fork an organizationally-managed repository, there's a good chance the owner doesn't want you to continue to have access to that codebase if you're no longer a part of the organization. And the local copy? Well there's a good chance you were only allowed to clone the repo on an IT-managed device with specific 2FA policies and some kind of agent/config to prevent/reduce data exfiltration from that device.

Is it a perfect system? Hell no. Data leaks, that's part of life. And I'm with you that it certainly could be more user-configurable.

But it's also extremely well-documented behavior[1], and seems like a key design choice that GitHub made a long time ago to protect the owners of private repos. Ultimately, if you don't care about who has access to your code, you signal that by making the repo public. Or by telling your private collaborators to make sure they hold on to a local copy.

[1]: https://docs.github.com/en/pull-requests/collaborating-with-...