Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Private Repos Considered Private-­Ish

tylercipriani.com

Post reply on HN
Print view View original

71–80 of 150 posts

Re: GitHub Private Repos Considered Private-­Ish

#71

Post by mtlmtlmtlmtl »

ethbr0 wrote: post #43
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.

I think 90s Microsoft could have something of a claim. It made a lot of sharp business choices in that decade, but it also left a LOT of money on the table for developers, as part of a strategic goal to grow the platform. Then the 00s came, platform growth slowed (because they were already running on everything desktop), and the "vs linux" decisions started coming.

Eh, I wouldn't say the say they handled the whole DR-DOS saga very reputably. And in 2001 they came to within an inch of their life in US v. Microsoft, a litigation mainly based on anticompetitive practices from the 90s.

Microsoft was disreputable in the 90s to the point they were almost broken up several times.

Re: GitHub Private Repos Considered Private-­Ish

#72

Post by rascul »

mtlmtlmtlmtl wrote: post #71
ethbr0 wrote: post #43

Earlier quoted context omitted.

I think 90s Microsoft could have something of a claim. It made a lot of sharp business choices in that decade, but it also left a LOT of money on the table for developers, as part of a strategic goal to grow the platform. Then the 00s came, platform growth slowed (because they were already running on everything desktop), and the "vs linux" decisions started coming.

Eh, I wouldn't say the say they handled the whole DR-DOS saga very reputably. And in 2001 they came to within an inch of their life in US v. Microsoft, a litigation mainly based on anticompetitive practices from the 90s. Microsoft was disreputable in the 90s to the point they were almost broken up several times.

Microsoft's battle against Netscape (which is also part of the show Valley of the Boom), and the Halloween documents, are two more examples.

Re: GitHub Private Repos Considered Private-­Ish

#73

Post by voakbasda »

mikeryan wrote: post #58
mtlmtlmtlmtl wrote: post #23

Earlier quoted context omitted.

Clearly they lied, if their policy says otherwise.

Their policy, if you scroll up from this link, is to scan only “aggregate metadata” and only if you opt in. GitHub aggregates metadata and parses content patterns for the purposes of delivering generalized insights within the product. It uses data from public repositories, and also uses metadata and aggregate data from private repositories when a repository's owner has chosen to share the data with GitHub by enabling…

What is AI training but “parsing content” for “delivering generalized insights”? They intentionally use slippery language that can defend their practices.

Re: GitHub Private Repos Considered Private-­Ish

#74

Post by hedora »

mikeryan wrote: post #58
mtlmtlmtlmtl wrote: post #23

Earlier quoted context omitted.

Clearly they lied, if their policy says otherwise.

Their policy, if you scroll up from this link, is to scan only “aggregate metadata” and only if you opt in. GitHub aggregates metadata and parses content patterns for the purposes of delivering generalized insights within the product. It uses data from public repositories, and also uses metadata and aggregate data from private repositories when a repository's owner has chosen to share the data with GitHub by enabling…

> 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 nice paper. I hope someone does it.

Re: GitHub Private Repos Considered Private-­Ish

#75

Post by awesometech »

blackoil wrote: post #28

Does the article has anything Github specific? All softwares can have bug so moving from Github to anything else is useless. VPN only self-hosted provides some additional protection but that's true for all cloud services like Jira, CI/CD and not a novel issue.

The article cites several GitHub incidents. If it can be verified GitHub competitors have a roughly equal number of incidents then the lack of novelty would be proven. I'm not supporting either view, just addressing your point.

Re: GitHub Private Repos Considered Private-­Ish

#76

Post by ec109685 »

trentnix wrote: post #62

A company I worked for a few years ago sold a source code license and I was tasked with sharing the source, sans history and only at a specific point in time, to the purchaser’s GitHub organization . I was told it had to be done as quickly as possible, and that we might do it a few more times so figure out a way to make it repeatable. I wrote a Bash script to copy our ~25 repositories to a new organization using the…

Any idea how successful the company who you sold sold the license to was with code base?

Trying to develop on a code base without history and a one time snapshot seems quite hard.

Re: GitHub Private Repos Considered Private-­Ish

#77

Post by hedora »

cj wrote: post #9

Recommendations missing from the article: - Enable mandatory 2fa within your Github organization (if you don't use an organization, you probably should) - Disable the ability to fork repos in your organization - Configure and enable mandatory SAML authentication. In combination with mandatory 2fa, this makes phishing and even key leakage less likely (specific keys need to be double authorized for SAML, so that random…

> Enable branch protection on master. Require at least 1 peer review to merge anything in it. Enforce branch restrictions to include repo admins so restrictions can't be bypassed. This should stop obvious mistakes like accidentally committing .git or random credentials.

Every team I've seen do this had their productivity drop by over a half when it was implemented. YMMV, but my normal heuristic is to see if I'm making 2x market value (due to stock vesting or whatever). If not, I dust off my LinkedIn profile and start catching up with old colleagues once this gets turned on.

The mindset that leads to enabling that policy implies a few bad things:

- The team has probably seen growing pains, but did not switch to feature branches for each team, which means it needs to have a release manager, but doesn't know what those people do.

- The product has inadequate testing, and there is no QA organization, and the mismanagement is creating revenue headwinds.

- Management doesn't trust prior hiring decisions, and has decided to treat the dev team like children (treating them like a cost center comes next).

- The company could be chasing revenue via regulatory compliance. There is a backwater of companies that adopt some viral compliance standard that mandates all suppliers also comply with the boneheaded compliance rules. This last reason is the least ominous of the possible reasons, and usually comes with checkbox style implementation of master protection (e.g., admins can override, and over half the team members are admins.)

Re: GitHub Private Repos Considered Private-­Ish

#78

Post by ec109685 »

smcleod wrote: post #12
jasoneckert wrote: post #6

This indirectly outlines one of the primary reasons organizations (like mine) prefer using GitHub Enterprise - we get the collaboration benefits of GitHub, but our data is entirely controlled and hosted by us. It's extra work and more costly overall, but it's a small price to pay for the data security.

I think you mean GitHub Enterprise Server. GitHub Enterprise is still a cloud / SaaS product.

Enterprise, even cloud hosted, would prevent things like a fork being public.

Re: GitHub Private Repos Considered Private-­Ish

#80

Post by yetanotherloss »

ckdarby wrote: post #10
jasoneckert wrote: post #6

This indirectly outlines one of the primary reasons organizations (like mine) prefer using GitHub Enterprise - we get the collaboration benefits of GitHub, but our data is entirely controlled and hosted by us. It's extra work and more costly overall, but it's a small price to pay for the data security.

From my perspective, the upkeep of maintaining such versions is far from trivial. It involves dedicated resources ensuring the regularity and reliability of backups. Furthermore, it's rare to find organizations conducting comprehensive disaster recovery (DR) restorations of their self-hosted GitLab or GitHub instances. This is typically due to an inherent expectation that each upgrade will proceed without hitches and…

As an aside, it remains funny to me how much effort organizations put into fighting NAT in 2023 instead of effort to just use ipv6.

Of course then there is the embarrassment of azure ipv6 so it's perhaps somewhat forgivable:)

Post reply on HN