GitHub Private Repos Considered Private-­Ish

Post by _joel » Mon, Jun 05, 2023, 1:11 PM UTC

cratermoon wrote: post #128

_joel wrote: post #7

Earlier quoted context omitted.

This. Every CI platform under the sun has support for secrets and config that should never live in git. It's worth ensuring people know this, of course, but I'm not sure storing secrets in git is all that prevelant. Many platforms also have secrets scanning to ensure you don't accidentally do this too.

> Many platforms also have secrets scanning to ensure you don't accidentally do this too. The reason secrets scanning even became a thing is because of how often secrets get committed to git. Some of them even lead to intrusions. Uber (2016) – Attackers gained unrestricted access to Uber’s private Github repositories, found exposed secrets in the source code, and used them to access millions of records in Amazon S3 b…

Post by halostatue » Mon, Jun 05, 2023, 1:23 PM UTC

edgyquant wrote: post #109

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.

For large projects this can happen. Think the Linux forks that AMD etc maintain and then regularly do a series of PRs to integrate them into some staging branch which then makes its way to the kernel if approved. It’s a typical workflow for inter-org codebase.

Post by halostatue » Mon, Jun 05, 2023, 4:52 PM UTC

waynecochran wrote: post #144

halostatue wrote: post #142

Earlier quoted context omitted.

This comment is complete FUD as you’re linking to a tertiary paragraph in a document describing how your data may be used if the owner of a private repository enable it, for such use as Dependabot, CodeQL, or secrets scanning. The top of the document is: > GitHub aggregates metadata and parses content patterns for the purposes of delivering generalized insights within the product. It uses data from public repositorie…

I call BS. OpenAI was originally meant to be an open source and non-profit company. It is now a closed source, for-profit company and is controlled by the company that gave FUD its original meaning for discrediting others who stood against it. It is supreme naivety to think they will not use whatever they can to gain power in the AI arena. There is nothing in that statement that a high powered lawyer can not twist an…

Post by halostatue » Mon, Jun 05, 2023, 9:16 PM UTC

waynecochran wrote: post #146

halostatue wrote: post #145

Earlier quoted context omitted.

OpenAI != GitHub even if GitHub has allowed training on public repositories (which I believe to be an absolute mistake because it should be preserving licensing on the processed repositories and we know that it is not doing so). There are many reasons to distrust Microsoft. The wording of this particular paragraph explaining how data gets used in accordance with the linked terms of service (which are the actual gover…

GitHub = MS, OpenAI = MS, so by transitivity OpenAI = GitHub (where = means "controlling or related interest"). I agree that the particular wording is not sufficient to specify much of anything, but does it sure doesn't shut the door on the possibility either.

Post by Drakim » Tue, Jun 06, 2023, 10:36 AM UTC

bluGill wrote: post #140

Drakim wrote: post #138

Earlier quoted context omitted.

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.