• MajorHavoc@programming.dev
    link
    fedilink
    arrow-up
    90
    arrow-down
    11
    ·
    edit-2
    5 months ago

    Misleading title.

    If my thing was public in the past, and I took it private, the old public code is still public.

    That’s… How the Internet works anyway.

    Edit: See Eager Eagle’s better explanation below.

    TL;DR - be careful who you allow to fork your private repos. And if you need to take a public repo, which has forks, private, consider archiving the repo and doing all the new work in a new repo. Which is arguably the reasonable thing to do anyway.

    Still a misleading title. This isn’t a way to break into all or even most of your private repositories.

    • morph3ous@lemmy.world
      link
      fedilink
      arrow-up
      28
      arrow-down
      1
      ·
      5 months ago

      That is not exactly what they are saying. You could create a private fork of a public repo and the code in your private fork is publicly accessible.

      • Eager Eagle@lemmy.world
        link
        fedilink
        English
        arrow-up
        29
        arrow-down
        1
        ·
        5 months ago

        I don’t think you can create private forks from public repos (the fork is public upon creation). This is more like the opposite:

        If there’s a private repo that is forked and the fork is made public, further changes to that original private repo become public too, despite the repo remaining private and the fork not being synced.

    • hedgehog@ttrpg.network
      link
      fedilink
      arrow-up
      14
      arrow-down
      2
      ·
      5 months ago

      Misleading title.

      The title literally spells out the concern, which is that code that is in a private or deleted repository is, in some circumstances, visible publicly.

      What title would you propose?

      If my thing was public in the past, and I took it private, the old public code is still public.

      The “Accessing Private Repo Data” section covers a situation where code that has always been private becomes publicly visible.

  • visor841@lemmy.world
    link
    fedilink
    arrow-up
    52
    arrow-down
    1
    ·
    edit-2
    5 months ago

    While this is still a massive problem, it does require a public fork at some point. So if you have a private repo that has never had a public fork, you should be safe.

      • hedgehog@ttrpg.network
        link
        fedilink
        arrow-up
        6
        ·
        5 months ago

        Yes, but only in very limited circumstances. If you:

        1. fork a private repo with commit A into another private repo
        2. add commit B in your fork
        3. someone makes the original repo public
        4. You add commit C to the still private fork

        then commits A and B are publicly visible, but commit C is not.

        Per the linked Github docs:

        If a public repository is made private, its public forks are split off into a new network.

        Modifying the above situation to start with a public repo:

        1. fork a public repository that has commit A
        2. make commit B in your fork
        3. You delete your fork

        Commit B remains visible.

        A version of this where step 3 is to take the fork private isn’t feasible because you can’t take a fork private - you have to duplicate the repo. And duplicated repos aren’t part of the same repository network in the way that forks are, so the same situation wouldn’t apply.

    • Aatube@kbin.melroy.org
      link
      fedilink
      arrow-up
      5
      arrow-down
      6
      ·
      edit-2
      5 months ago

      sourcehut is much better if you can pay

      Edit: Only repo hosters need to pay. Everything else is free.

      • hedgehog@ttrpg.network
        link
        fedilink
        arrow-up
        6
        ·
        5 months ago

        What makes sourcehut better?

        From a self-hosting perspective, it looks like much more of a pain to get it set up and to keep it updated. There aren’t even official Docker images or builds. (There’s this and the forks of it, but it’s unofficial and explicitly says it’s not recommended for prod use.)

        • Aatube@kbin.melroy.org
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          edit-2
          5 months ago

          Sourcehut has straightforward much better UI, UX, and features (more than gitea/forgejo but less than GitLab ig). I really dig the subdomain design.

          Issues and PRs are conducted through email, essentially making that part federated and signup-less.

          I’ve seen many pieces of software that claim to be beta/not used for prod but are actually bedrock solid.

  • nao@sh.itjust.works
    link
    fedilink
    arrow-up
    12
    arrow-down
    4
    ·
    5 months ago

    After reviewing the documentation, it’s clear as day that GitHub designed repositories to work like this.

    Sounds like they wanted to find a problem but it turned out to be a feature.

    • Shadow@lemmy.ca
      link
      fedilink
      arrow-up
      12
      arrow-down
      3
      ·
      5 months ago

      Yeah, pretty much everyone agrees that once something goes to git it lasts forever.

      The fact they call out that secret keys must be rotated if committed, makes me think they thought just deleting a commit was enough 🤦

  • youmaynotknow@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    5 months ago

    Just this week I migrated all my repos from github to Gitlab. And only because I can’t host my own gits just yet, but will do it soon enough.