Your Private GitHub Repos Aren't as Private as You Think

Why is no one talking about this?

Sources:

Algo spam (just the transcription of the video intro):

If you thought your private GitHub repositories were safe from prying eyes, think again.
This blog post caught my attention today, and I'm kind of surprised that no one's talking
about it because this seems like a big deal.
Anyone can access deleted and private repository data on GitHub.
Specifically, you can access data from deleted forks, deleted repositories, and even private
repositories on GitHub, and it's available forever.
This is known by GitHub and intentionally designed that way.
That's right, this is a feature, not a bug.

[christianbarnay]

The issue is not that the feature exists and works as documented. The issue is that it deliberately uses misleading terms.
"Delete" that doesn't actually delete data should not be labelled "Delete".
"Private" that doesn't actually make data private should not be labelled "Private".

[lis]

i've read somewhere that "Delete" of something in the cloud can be translated to "make it inaccessible for me".

[TheDeadSource]

Exactly why new coders are advised to **never** hardcode sensitive data
edit: ah, it got worse after I made that comment

[stevencoghill]

You know. Words mean things. So people think things marked PRIVATE are, you know, PRIVATE. Same with deleted. So people don't delve into the bowels of documentation because they know what words mean. The don't think that a 3rd party went and redefined the words out from underneath them. Another example recently is that Ohio has declared that boneless wings are allowed to have bones in them. Sorry, the rest of the world stupidly believes that boneless wings are sans bones. Silly rabbit. GitHub, don't hide behind the fine print. Tell people upfront what your terms mean. Another approach would be for GitHub to provide an ERASE feature. Kinda like when you delete a file, it's not really gone. Just the pointer is gone. But, if you erase it, then the data is gone too.

[Otakutaru]

please... Turn off the face tracker, it's the most distracting thing after tik tok car slides.

[meyes]

"There is nothing you can do to remove that data"
**Laughs in filing a GDPR "right to be forgotten" request**

[gamingtech]

Ah... The "you're holding it wrong" response

[SourceOfViews]

To those saying "this is a git issue": No it's not.

Git doesn't have any concept of forks on the same host (unless you consider worktree that, but it really isn't the same). Initially, people sent git repos directly to each other. When you had a fork, you had a copy of the original at the time of forking, but the original has NO knowledge of you. Likewise, the fork has NO information about the original outside of possibly an URI to it.

Personally I'd expect that if I delete a repository, it should actually delete the repository. There is really no reason why I'd still need the commits in any other repository, fork or not.
Of course it makes sense to store the same commits in multiple repositories together to save space, but unreferenced commits really should not ever be transfered.
This just sounds like they did not want the additional risk of fucking this up or of people doing weird shit, like using a commit hash in their scripts, because they don't understand git gc.

[MatthieuPETIOT]

Title should be: Private forked github directory are not as private as you think.

[ross]

You can email support and just politely ask them to move your private repo to it's own fork network separate from the upstream. That's the solution I have used.

[sitrilko]

This sounds like a GDPR-bomb waiting to implode upon Github.

[mdski]

TLDR; privacy you want – fork you do not. as separate remote a new GH repo you create

[bl]

Thanks, I was not aware of this.
IMHO, they should probably change the word "Delete" to something else, and had a short reminder in the "delete verification" dialog, that public repos are never rely deleted (with link to doc). There should be a similar reminder when making a private repo public.

Glad that I setup my private Gitea all those years ago...

[th_CAV_Trooper]

My git hub repos are exactly as private as I think. They're set to public. Seriously though, sharing this at work.

[rtsa]

Crazy coincidence that I was just thinking about if private GitHub repos not being private as a random passing thought and this video popped up in my feed shortly afterwards.

[jaykay]

Things like this are the reason why we consider API keys committed to a repo a security incident. Regardless whether it's public or private. Resolving the incident is only possible by revocing the key.

[jacmkno]

Fair enough, make it a feature. But this should show up a a clear explicit warning in the UI at least in the case when you are making public a private repo with forks.

[julytikh]

So, to summarize:
1. Data once made public stays public. Perfectly reasonable, this is how Internet works. If you publish a secret, you cannot delete it, only invalidate it. No surprise here at all.
2. Purely public workflow works as intended.
3. Purely private workflow works as intended.
4. Mixed public-private workflow may have some hidden traps. Well, maybe GitHub should put some kind of notice on switching repo form private to public, like “this can expose private data even beyond what is contained in the repo”. Other than that, the behavior is rather reasonable once you read the documentation. (Personally, I would not perform such a switch at all, just to avoid reasoning about the consequences. Creating a new public repo and pushing the necessary commits to it is a viable alternative.)

[JC-shim]

Aaand.. that's why anything you want to keep private, just don't put it into the clouds, period. Everything will be made public eventually. You keep it in a loca self-hosted repo etc. Never know when and how, but stuff like that will keep happening.

[metalstarver]

If I understood correctly, if I make private repo from scratch and don't do any fork of it then it still will truly be private? Issue is only when forks are involved?