GitHub Private Repos Considered Private-Ish • Hacker News Board

Re: GitHub Private Repos Considered Private-Ish

#111

Post by electroly » Sun, Jun 04, 2023, 5:27 PM UTC

solatic wrote: post #89

sobellian wrote: post #41

Earlier quoted context omitted.

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.

That one has an easy fix: store secrets in a separate repo that you never roll back. That's not the reason to avoid storing secrets in git. You might be giving some junior dev here the idea that if they can solve this issue, then storing secrets in git will be ok. Obviously it's not; it's still a bad idea after you've solved this minor annoyance and, indeed, this annoyance had nothing to do with the security reason why you don't store secrets in git.

Re: GitHub Private Repos Considered Private-Ish

#112

Post by Fogest » Sun, Jun 04, 2023, 5:33 PM UTC

awesometech wrote: post #84

yetanotherloss wrote: post #80

Earlier quoted context omitted.

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.

My ISP still doesn't even support ipv6. From my limited understanding that itself would already make it a problem to access an ipv6 only site.

Re: GitHub Private Repos Considered Private-Ish

#113

Post by flerchin » Sun, Jun 04, 2023, 5:42 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.

Every single clone is a fork. I feel like you're missing the fundamental concept of git as a DVCS.

Re: GitHub Private Repos Considered Private-Ish

#114

Post by howinteresting » Sun, Jun 04, 2023, 6:10 PM UTC

flerchin wrote: post #113

cj wrote: post #94

Earlier quoted context omitted.

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

Every single clone is a fork. I feel like you're missing the fundamental concept of git as a DVCS.

They clearly mean fork in the GitHub UI, not fork as in running git clone locally.

Re: GitHub Private Repos Considered Private-Ish

#115

Post by cj » Sun, Jun 04, 2023, 6:32 PM UTC

flerchin wrote: post #113

cj wrote: post #94

Earlier quoted context omitted.

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

Every single clone is a fork. I feel like you're missing the fundamental concept of git as a DVCS.

GitHub support disagrees: https://github.com/orgs/community/discussions/35849

Clone = copy of code that you can sync with the remote on GitHub

Fork = copy of code that isn’t connected to the original remote. Of course, every fork involves a clone. But not every clone is a fork.

I could be wrong, but “fork” isn’t really a concept native to Git.

https://en.m.wikipedia.org/wiki/Fork_(software_development)

Re: GitHub Private Repos Considered Private-Ish

#116

Post by sobellian » Sun, Jun 04, 2023, 6:45 PM UTC

solatic wrote: post #89

sobellian wrote: post #41

Earlier quoted context omitted.

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.

This assumes that the secrets are deployed along with everything else in the repository. Even if the same repository contains your app, they needn't be deployed together. And as far as old secrets go, they are at most as sensitive as current secrets.

Re: GitHub Private Repos Considered Private-Ish

#117

Post by ethbr0 » Sun, Jun 04, 2023, 6:47 PM UTC

rascul wrote: post #72

mtlmtlmtlmtl wrote: post #71

Earlier quoted context omitted.

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.

It bleeds over into ethics at some point.

Microsoft in the DOS days was still fighting hard for market. Microsoft in the Netscape days? Eh... less of a competitive claim. Post ~2005? No claim.

For me, the definition of "reputable" changes when you're a competitor among equals vs when you're a monopoly.

Re: GitHub Private Repos Considered Private-Ish

#118

Post by api » Sun, Jun 04, 2023, 6:54 PM UTC

gumballindie wrote: post #19

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

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.

Many SaaS companies probably double dip by monetizing customer data in various ways. Good luck even knowing if it’s happening and if you do figure it out I’m sure the EULA will be properly one sided.

Can you imagine how much intel Google Docs, GMail, Salesforce, Profitwell, etc have about company performance and plans?

I’m sure nobody is using any of that data to insider trade, to give just one example. Nobody would do that.

Re: GitHub Private Repos Considered Private-Ish

#119

Post by hakre » Sun, Jun 04, 2023, 8:39 PM UTC

atq2119 wrote: post #95

hakre wrote: post #30

Earlier quoted context omitted.

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.

oh snap, too late to edit ... you are absolutely right.

Re: GitHub Private Repos Considered Private-Ish

#120

Post by Drakim » Sun, Jun 04, 2023, 9:28 PM UTC

bluGill wrote: post #47

Drakim wrote: post #5

Earlier quoted context omitted.

Yeah, I reacted to that too. It's like nonchalantly saying that you have all your passwords written on post-it notes at your desk. The topic of discussion shouldn't be how to secure your desk from spying eyes, but about why having post-it notes with passwords is bad practice and just a bad idea overall. If your private github repo accidentally goes public, the response should be "that's annoying but ultimately harmle…

Postits for passwords are better practice than memorizing passwords. If you can memorize it, it is a bad password. Password managers are better yet, but you still need the master password. The problem is not keeping those passwords in a secure location, treat it like a stack of $100 bills.

For your home desk? I can buy that. But for your work desk? No way is that even remotely more acceptable than having a memorizable password.