GitHub Private Repos Considered Private-Ish
tylercipriani.com
GitHub Private Repos Considered Private-Ish
1–10 of 150 posts
Re: GitHub Private Repos Considered Private-Ish
#2> We cram our secrets into git
Excuse me?!
Re: GitHub Private Repos Considered Private-Ish
#3> We cram our secrets into git Excuse me?!
What for? I've seen this happening and if there would not have been a review, it would have stayed there unnoticed.
/edit:
Also what someone considers a secret and then not, is often not well defined. If management has no clue what this is about, it is often better to only commit and push on direct and simple work order, because these need to be well understood and you have the paper trail (as that author also suggests blameful retrospectives - IMHO hilarious).
Or do we have forgotten about the basic rules sending data over the interwebs to other people computers?
Re: GitHub Private Repos Considered Private-Ish
#4> We cram our secrets into git Excuse me?!
It’s slightly annoying when someone blunts doing something dumb by declaring some form of “we all do it.”
Re: GitHub Private Repos Considered Private-Ish
#5> We cram our secrets into git Excuse me?!
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 harmless", anything else is misguided.
Re: GitHub Private Repos Considered Private-Ish
#6This 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.
Re: GitHub Private Repos Considered Private-Ish
#7> We cram our secrets into git Excuse me?!
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.
Re: GitHub Private Repos Considered Private-Ish
#8> We cram our secrets into git Excuse me?!
[deleted]
Re: GitHub Private Repos Considered Private-Ish
#9Recommendations 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 private key you have on a random CI/CD platform from a few years ago can't access repos in SAML organizations even if it's leaked)
- Disable the ability to make repos public at the organization level
These are some quick setting changes that should address at least 3 of the 4 main issues in the article.
Additional suggestion:
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.
Edit: if the author sees this, feel free to add these things to the article!
Re: GitHub Private Repos Considered Private-Ish
#10This 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 yield flawless operation.
Moreover, the process of securing approval for NAT inbound rules, particularly for integrations with services like Jira, Slack and so on, often turns into a labyrinthine ordeal. It usually involves navigating the differing viewpoints and interpretations across multiple departments, each with its own unique stance, which further exacerbates the complexity of the task.