GitHub Private Repos Considered Private-Ish • Hacker News Board

Re: GitHub Private Repos Considered Private-Ish

#91

Post by rvz » Sun, Jun 04, 2023, 3:42 PM UTC

Unsurprising. Private repositories are not 'private' [0] and GitHub, Microsoft and OpenAI are thanking you for allowing them to train their AI on your so-called 'private' code. [1]

This is essentially a shameless admission and they not even hiding it any more:

Private repository data is scanned by machine and never read by GitHub staff. Human eyes will never see the contents of your private repositories, except as described in our Terms of Service.

This is another great reason to self host instead of using services like GitHub openly reading your private code, which I have been saying for years.

[0] https://news.ycombinator.com/item?id=34258431

[1] https://docs.github.com/en/get-started/privacy-on-github/abo...

Re: GitHub Private Repos Considered Private-Ish

#92

Post by sebzim4500 » Sun, Jun 04, 2023, 3:42 PM UTC

Zemtomo wrote: post #83

Zemtomo wrote: post #64

Earlier quoted context omitted.

IP theft? Just code is not an IP. Your product or a specific algorithm is. And in my opinion patent on algorithm should be illegal. There.is no inherent problem hosting Code on GitHub. You are not doing a good job if you move companies away from working setups due to this. And they haven't had high security requirements anyway because everyone else normally hosts GitHub Enterprise or gitlab themselfs

I'm always surprised that there are always people in hn liking software patents. But sure have your opinion but at least try to bring your issue actoss

I don't think anyone on HN likes software patents but god damn do they love copyright of code.

Re: GitHub Private Repos Considered Private-Ish

#93

Post by sebzim4500 » Sun, Jun 04, 2023, 3:45 PM UTC

>We cram our secrets into git, then shove it off to the most expansive code forge in the history of humanity

Do we? Putting secrets in git is against policy almost everywhere.

Re: GitHub Private Repos Considered Private-Ish

#94

Post by cj » Sun, Jun 04, 2023, 3:48 PM UTC

hedora wrote: post #81

cj wrote: post #21

Earlier quoted context omitted.

It prevents it from happening in the GitHub UI. Of course it’s still possible to download the code and upload it to a separate repo (but then it’s not a fork).

Of course bypassing the UI means that normal development flows (like force rebasing, or futzing with the CI setup) now are the same set of commands as malicious exfiltration of source code. It also breaks GitHub's normal protection against accidentally creating public forks of private repos (and the feature where it auto-deletes your private forks when you change jobs). There are probably other ways in which disablin…

(Genuine question) what is a use case where an employee needs to fork your company’s repo rather than open a PR?

The only one I can think of is what you mentioned (testing CI workflows that match a branch name) but at least at our company that can usually be done in a PR.

I don’t see any obvious reason why an employee would ever need to fork a company’s private repo to their personal GitHub account.

Re: GitHub Private Repos Considered Private-Ish

#95

Post by atq2119 » Sun, Jun 04, 2023, 4:13 PM UTC

hakre wrote: post #30

capableweb wrote: post #22

Earlier quoted context omitted.

> formerly reputable corporations I'm sorry but when was Microsoft ever reputable? They have a long history (and reputation) of being merciless in every single way they can, and have for as long as I can remember.

A cooperation is never reputable. It is easier to reason with a dog than with a cooperation. However, me thinks this relates to the times before Github became an offering by Microsoft. But the deal was just too hard to miss, getting this massive army of minion coders who all pray to the octocat and now do the Balmers dance. Oh so much fun, now it turns out, that all feed the new AI overlords.

That misspelling of "corporation" severely breaks the meaning you almost certainly intended.

Re: GitHub Private Repos Considered Private-Ish

#96

Post by atq2119 » Sun, Jun 04, 2023, 4:16 PM UTC

simonw wrote: post #86

hedora wrote: post #74

Earlier quoted context omitted.

> The information we learn only comes from aggregated data It seems pretty clear to me that this means they're allowed to use private repos to train copilot, etc. I wonder if any researchers have tried putting fingerprinted source code into a private repo, and then (after it is retrained) getting copilot to suggest stuff that could only have come from the injected supposedly-private source code. That would make a nic…

I genuinely don't see how "The information we learn only comes from aggregated data" relates to training LLMs, which need raw data, not aggregated data, as their input. Maybe we have different definitions of the term "aggregated"? This suggests to me that GitHub need to extend that text to explain what they mean by "aggregated".

The LLM itself is a form of aggregated data.

Re: GitHub Private Repos Considered Private-Ish

#97

Post by jononomo » Sun, Jun 04, 2023, 4:23 PM UTC

Have you guys considered the machines are reading your private repos all the time? Forget about LLMs -- what about your text editor? Also, it is likely that your browser has access to your private repo when you use your browser to browse your private repo.

Re: GitHub Private Repos Considered Private-Ish

#98

Post by simonw » Sun, Jun 04, 2023, 4:23 PM UTC

atq2119 wrote: post #96

simonw wrote: post #86

Earlier quoted context omitted.

I genuinely don't see how "The information we learn only comes from aggregated data" relates to training LLMs, which need raw data, not aggregated data, as their input. Maybe we have different definitions of the term "aggregated"? This suggests to me that GitHub need to extend that text to explain what they mean by "aggregated".

The LLM itself is a form of aggregated data.

Sure, but the raw training data isn't.

I think GitHub need to clarify this themselves.

Re: GitHub Private Repos Considered Private-Ish

#99

Post by 3np » Sun, Jun 04, 2023, 4:27 PM UTC

blackoil wrote: post #33

3np wrote: post #18

Earlier quoted context omitted.

Your other points are useful but I find the below questionable and counterproductive: > - Disable the ability to fork repos in your organization If someone can read it, they can trivially fork it (clone locally, then republish as new repo). The only thing you're preventing with this advice is the free discoverability and tracking of forks which you get with forks created with the GitHub "fork" button. The forks are s…

The idea is to protect against accidental sharing. A rogue employee can simply take dump and share on 4Chan no matter what tools you use.

Forks of private repos are similarly private by default, with some hoops and warnings before you can extend it. I still dont see how that recommendation brings any benefits in this regard.

Re: GitHub Private Repos Considered Private-Ish

#100

Post by owl57 » Sun, Jun 04, 2023, 4:29 PM UTC

cj wrote: post #94

hedora wrote: post #81

Earlier quoted context omitted.

Of course bypassing the UI means that normal development flows (like force rebasing, or futzing with the CI setup) now are the same set of commands as malicious exfiltration of source code. It also breaks GitHub's normal protection against accidentally creating public forks of private repos (and the feature where it auto-deletes your private forks when you change jobs). There are probably other ways in which disablin…

(Genuine question) what is a use case where an employee needs to fork your company’s repo rather than open a PR? The only one I can think of is what you mentioned (testing CI workflows that match a branch name) but at least at our company that can usually be done in a PR. I don’t see any obvious reason why an employee would ever need to fork a company’s private repo to their personal GitHub account.

> I don’t see any obvious reason why an employee would ever need to fork a company’s private repo to their personal GitHub account.

I don't see it as well, but Github docs seem to suggest that forking a private repo inside the same org is allowed/forbidden by the same setting?