GitHub Private Repos Considered Private-Ish • Hacker News Board

Re: GitHub Private Repos Considered Private-Ish

#131

Post by hedora » Mon, Jun 05, 2023, 1:56 AM UTC

cj wrote: post #90

hedora wrote: post #77

Earlier quoted context omitted.

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

> requiring peer reviews

I didn’t say anything about peer reviews.

Regarding the rest of your comment:

- if you are committing to a branch directly that then immediately goes to production you are doing something horribly wrong

- having a formal process for code reviews is like making sure there is a formal process to make sure employees wear pants to work. If this sort of thing has to be policed by security settings in the dev environment, then something deeper is wrong.

I mostly work on safety critical code, so I know what it means to ship a mission critical code base.

Most of the things you allude to suggest that you’ve never worked with a competent release manager or qa organization.

Edit: also:

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

This is only true for definitions of “productivity” that exclude security/quality control, which usually mean that things are so out of whack, it is time to find a new job. By definition, the “productive” people aren’t worrying about product quality, and are being promoted for it, so soon the organization will be run by people that sabotaged the business.

Re: GitHub Private Repos Considered Private-Ish

#132

Post by hedora » Mon, Jun 05, 2023, 2:05 AM UTC

atq2119 wrote: post #103

simonw wrote: post #98

Earlier quoted context omitted.

Sure, but the raw training data isn't. I think GitHub need to clarify this themselves.

Sure. All aggregated data is ultimately derived from raw, unaggregated data. One can make the argument that training an LLM is "just" an unusually complicated form of aggregation. Whether that would hold up is another question. But yeah, I agree with the conclusion that they need to clarify this.

Training the LLM is a form of “learning”, and putting all the data in an input training set is a form of aggregation.

The clause seems to mean “we can do whatever we want with your data as long as we violate many people’s privacy at scale at the same time”.

Re: GitHub Private Repos Considered Private-Ish

#133

Post by cj » Mon, Jun 05, 2023, 3:01 AM UTC

hedora wrote: post #131

cj wrote: post #90

Earlier quoted context omitted.

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…

> requiring peer reviews I didn’t say anything about peer reviews. Regarding the rest of your comment: - if you are committing to a branch directly that then immediately goes to production you are doing something horribly wrong - having a formal process for code reviews is like making sure there is a formal process to make sure employees wear pants to work. If this sort of thing has to be policed by security settings…

> Most of the things you allude to suggest that you’ve never worked with a competent release manager or qa organization.

You’re right, I oversee an 8 person product team for a 20 person company. Not a huge organization. QA is a shared function and we don’t have a “release manager” on staff.

I’m genuinely confused about what you’re trying to say. Sounds like you’ve had a bad experience with branch restrictions. It would be interesting to hear what the workflow was and how branch restrictions, etc, got in your way.

Re: GitHub Private Repos Considered Private-Ish

#134

Post by bluGill » Mon, Jun 05, 2023, 3:05 AM UTC

Drakim wrote: post #120

bluGill wrote: post #47

Earlier quoted context omitted.

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.

You don't leave them on the desk. Lock them up with a key. Every office gives you file cabinet that locks.

Re: GitHub Private Repos Considered Private-Ish

#135

Post by rascul » Mon, Jun 05, 2023, 3:17 AM UTC

ethbr0 wrote: post #117

rascul wrote: post #72

Earlier quoted context omitted.

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.

They were a monopoly since the '90s.

Re: GitHub Private Repos Considered Private-Ish

#136

Post by sebazzz » Mon, Jun 05, 2023, 4:49 AM UTC

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…

You can also just use Github Enterprise. You're on Github.com but in a completely separate tenant and any collaboration outside of your tenant is impossible: you're recognised but it says you're not allowed.

Re: GitHub Private Repos Considered Private-Ish

#137

Post by tessierashpool » Mon, Jun 05, 2023, 5:11 AM UTC

capableweb wrote: post #22

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.

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

GP said: 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.

you said: I'm sorry but when was Microsoft ever reputable?

nobody said Microsoft had ever been reputable.

GitHub is the formerly reputable corporation here.

GP comment doesn't even make sense without that.

Re: GitHub Private Repos Considered Private-Ish

#138

Post by Drakim » Mon, Jun 05, 2023, 10:11 AM UTC

bluGill wrote: post #134

Drakim wrote: post #120

Earlier quoted context omitted.

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.

You don't leave them on the desk. Lock them up with a key. Every office gives you file cabinet that locks.

That's basically an analog password manager, we have gone full circle.

Or we return the metaphor to github repos, having a separate cabinet is like having a secret vault so that secrets are not directly in plain view in the repo itself, which is exactly what you should be doing.

Re: GitHub Private Repos Considered Private-Ish

#139

Post by gymbeaux » Mon, Jun 05, 2023, 11:15 AM UTC

snowwrestler wrote: post #48

It’s right there in the name: GitHub private repos are “private,” not “secure” or “secret”. That name was chosen purposefully. When we moved our code from privately hosted SVN to GitHub 10+ years ago, folks at GitHub were quite clear that we should not trust private repos with secrets like private keys or passwords. So why have private repos at all? It is to allow control of collaborators. GitHub originally allowed e…

I don’t think it was “chosen very carefully”- the other word is “public”, and it refers mainly to who has access to the repo. Public and private are the ideal words imo

Re: GitHub Private Repos Considered Private-Ish

#140

Post by bluGill » Mon, Jun 05, 2023, 12:33 PM UTC

Drakim wrote: post #138

bluGill wrote: post #134

Earlier quoted context omitted.

You don't leave them on the desk. Lock them up with a key. Every office gives you file cabinet that locks.

That's basically an analog password manager, we have gone full circle. Or we return the metaphor to github repos, having a separate cabinet is like having a secret vault so that secrets are not directly in plain view in the repo itself, which is exactly what you should be doing.

Not quite full circle as we have now agreed that writing your passwords down on paper is acceptable.