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

81–90 of 150 posts

Re: GitHub Private Repos Considered Private-­Ish

#81

Post by hedora »

cj wrote: post #21
flerchin wrote: post #14

Earlier quoted context omitted.

What does "Disable the ability to fork repos in your organization" do? Isn't that entirely defeated by users changing the origin?

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 disabling private forks undermines your organization's security, but those are pretty obvious.

Re: GitHub Private Repos Considered Private-­Ish

#82

Post by awesometech »

p-e-w wrote: post #36

This post is mostly FUD. Case in point, the following advice: > So, if you’re worried about it: stop putting sensitive data into private repositories. Most of the issues mentioned in the post (misconfiguration, phishing, mistakes, zero-days) apply to all software, including non-cloud software. So the above advice is equivalent to "stop putting sensitive data into computers". It's run-of-the-mill popular-security nons…

> Most of the issues mentioned in the post

...are directly attributed to the cited GitHub incidents. I only scanned the article once but I saw no FUD in it.

Re: GitHub Private Repos Considered Private-­Ish

#83

Post by Zemtomo »

Zemtomo wrote: post #64
gumballindie wrote: post #19

Earlier quoted context omitted.

Thats the main reason i moved my code away from github and am advising clients to follow suit. It boggles the mind that we have to actively police against ip theft by formerly reputable corporations but here we are.

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

Re: GitHub Private Repos Considered Private-­Ish

#84

Post by awesometech »

yetanotherloss wrote: post #80
ckdarby wrote: post #10

Earlier quoted context omitted.

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:)

There are many valid reasons to not use IPv6, it would make an interesting HN article.

Re: GitHub Private Repos Considered Private-­Ish

#85

Post by simonw »

waynecochran wrote: post #13

Don’t forget OpenAI and Microsoft using your github data for training GPT. Their privacy statement says your content will not be read by “human eyes.” https://docs.github.com/en/get-started/privacy-on-github/abo...

I don't think it's right to conclude "your private repo data will be used to train GPT" based on the text you linked to there.

Re: GitHub Private Repos Considered Private-­Ish

#86

Post by simonw »

hedora wrote: post #74
mikeryan wrote: post #58

Earlier quoted context omitted.

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 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".

Re: GitHub Private Repos Considered Private-­Ish

#87

Post by chrsig »

pydry wrote: post #69
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'm sorry but when was Microsoft ever reputable? They went on an open source charm offensive a few years ago. "Oh, we've turned over a new leaf" etc. A lot of people believed that they'd had a legitimate change in heart because of the change in strategy. More realistically, Linux had driven them into near irrelevance in the server market and just pushed them from "extinguish" or "extend" to "embrace". Their dubious…

> More realistically, Linux had driven them into near irrelevance in the server market and just pushed them from "extinguish" or "extend" to "embrace".

and with vscode, copilot, and wsl2 they're doing a terrifyingly good job :-/

I really hope people don't let their guard down.

Re: GitHub Private Repos Considered Private-­Ish

#88

Post by chrisfosterelli »

bluGill wrote: post #32
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…

But now it becomes a harder mistake to make. Creating a new repository is easy, but not so easy you would do it by accident. Importantly when this is discovered you can fire the person who did it, and they can't say it's was an accident, while the fork button to the wrong place is potentially an accident.

You can't accidentally share a private fork any easier than you could a new repo. If you try to make a private fork public in GitHub there is just a message that "For security reasons, you cannot change the visibility of a fork."

As far as I know the article's example of 'a developer forks a private repo and makes it public' is not possible in github.

Re: GitHub Private Repos Considered Private-­Ish

#89

Post by solatic »

sobellian wrote: post #41
justizin wrote: post #2

> We cram our secrets into git Excuse me?!

Some folks use tools like https://github.com/mozilla/sops to store most secrets (besides the sops key, of course) in source control. Of course, you aren't committing the cleartext but if the repo gets published you should probably rotate your keys just to be safe...

Even this I would consider to be bad practice. Old versions of secrets are never relevant. Easy way to break your system:

1. Write code v1 2. Add secret 3. Write code v2 4. Rotate secret 5. Oops, some kind of problem, let's go back to known-good and redeploy (2). Broken because it tries the older secret, not the rotated secret.

Just don't store secrets in version control.

Re: GitHub Private Repos Considered Private-­Ish

#90

Post by cj »

hedora wrote: post #77
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 makin…

Edit: Longer response below, but if requiring peer reviews triggers you to start looking for a new job, what does your dev workflow look like? Do you do peer reviews at all or only sometimes?

Admittedly, branch protection requiring peer review into master was something we started for SOC 2 compliance.

But, it’s actually great if implemented well.

Some suggestions:

- Limit the use of “master” branch to code currently deployed to production (don’t use master to stage code that hasn’t been deployed yet). This branch should have the strictest restrictions (no admin override) because merging anything into this branch only happens immediately before a deploy. This also allows your team to assume that any pushes to master should/could trigger an automated deploy workflow

- Have a release branch where all PRs are merged/squashed into. Use this branch as the base branch for all PRs. At our company this is simply the “staging” branch. This branch can have looser restrictions (allow overriding restrictions). The release branch is anything that’s going to be deployed in the next release. Merged into the release branch can trigger automatic deploys to staging for QA team to do any final functional testing before code gets to production

- Or for a smaller company, don’t have any restrictions on the release branch. You’ll still be in compliance with all frameworks because, at a minimum, no code gets to production without a peer review (because the entire release branch has to be peer approved before it can be merged to master)

- Still allow hotfix PRs into master if you need to deploy something urgently without deploying the release branch. But hotfixes ideally should be rare (if they happen all the time it means you’re deploying a lot of buggy code to production and probably need to do better testing/QA)

There’s always a balance between security/quality control and productivity.

At the absolute minimum, you really should enable branch restrictions even if the only restriction is requiring all merges come from a PR. This will block developers accidentally force pushing their local master and potentially overwriting master branch completely (this has happened at our company prior to enabling restrictions, and it required another developer force pushing their, more up to date, local master to resurrect the correct state)

The goal should be to block actions that are obviously bad in all cases (e.g. pushing a commit directly to master without a PR).

Whatever your branch restrictions are, they should align with whatever your company’s internal code review processes are. Then, the branch restrictions are simply acting as a fall back in case developers make a mistake (e.g. avoids merging/pushing to master by accident)

For a small startup, all this advice is irrelevant because you probably care a lot more about how fast you can pump out changes and care much less about bugs getting into prod. And that’s fine.

These suggestions are mostly relevant for mission critical code bases where the restrictions align with your QA process. The branch restrictions should be enabled after documenting a QA process. Branch restrictions should not be arbitrarily enabled if the reasons for the restrictions don’t align with your existing internal processes/workflows.

Post reply on HN