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

35,176
0
Publicado 2024-07-26
Why is no one talking about this?


Sources:
trufflesecurity.com/blog/anyone-can-access-deleted…
trufflesecurity.com/blog/secrets-are-not-a-code-se…
github.com/yt-dlp/yt-dlp/commit/cb91b4dd
www.gharchive.org/
github.com/security


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.

Todos los comentarios (21)
  • @thehint1954
    Private repos - well its where i keep all my broken code, good luck with that
  • @TheDeadSource
    Exactly why new coders are advised to *never* hardcode sensitive data edit: ah, it got worse after I made that comment
  • 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.
  • @JC-sh6im
    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.
  • @whyredfire
    12:03 "The author of the blog post agrees with me" lol, it's you who is agreeing with the author as the blog was written prior to you reading it.
  • @mdski95
    TLDR; privacy you want – fork you do not. as separate remote a new GH repo you create
  • @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.
  • My git hub repos are exactly as private as I think. They're set to public. Seriously though, sharing this at work.
  • @PauxloE
    My employer's Open Sourcing Guidelines say to make a copy of the latest state of the internal repository when making it public. So no sharing of commits. (We are using an internal Github Enterprise anyways, let's see how this changes when we migrate to Github Enterprise Cloud.)
  • @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.)
  • @PauxloE
    From my understanding, one goal behind this is to allow restoring pull requests to your repository even if the PR author deleted the branch or repository. Plus of course, saving storage space by not duplicating data across forks.
  • With API keys, you can just rotate the key, like you said. What's really scary is when you have a private fork with paid features, this is a big business risk
  • @metalstarver642
    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?
  • So from my understanding, you need to create a fork as a prerequisite. What happens if you don't? Also, deleted repos are not fully deleted for at least three months.
  • This sounds like a GDPR-bomb waiting to implode upon Github.
  • @pomp0m
    This is Git as designed, Everything is remembered and nothing is deleted. That's why education on usage is always: "Never put secrets in version managment" And also If it happens, don't just remove but recreate secrets. It's like putting a sticker on your car with your password and then setting the car in the sun. If you remove them you still see the text so if you where doing a human (bit stupid) mistake of putting your password on your car for everyone to see you don't remove the sticker but you change your password.