Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They buried the lede[1]:

> Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised.

I've never understood why people want to dump their config files on a public server. The "reasons" given are unconvincing:

* "Backup, restore, and sync" -- I don't keep the rest of my backups out in the open.

* "Learn" -- Maybe, but I prefer learning from stuff people have taken the time to deliberately share.

* "Share" -- I'd rather explicitly choose what I share.

[1] https://help.github.com/articles/remove-sensitive-data/




In principle your dotfiles shouldn't contain any sensitive data. It's not burying the lede, it's just that you read the article and decided that some important warning was so important that it was the purpose of the whole piece.

The reasons they offer might not be the most convincing, but they're something, which is better than nothing. Suppose you have a bunch of configuration that you're sure contains no sensitive information and you've decided to sync it between machines somehow. Why not use github, assuming you're already a github user.


I agree with you in principle, but in practice putting your config on GitHub is asking to be pwned. If you put your personal config on a public server, the odds are good that you'll eventually leak some information you shouldn't have. If you're lucky, Amazon's bot will find the API key and disable it, and you'll waste a bit of time getting a new one. If you're less lucky, you'll pay for someone's bitcoin miner. If you're unlucky, someone will quietly pwn you bit by bit, it will take you months or years to discover it, and you may never figure how how they did it.

When "scp" and "rsync" exist, and git is a distributed version control system, it's hard to justify unnecessarily exposing data on the web.


The solution I use to this issue, which I think is fairly straightforward, is to put any sensitive information such as credentials, or things that others don't care about such as aliases to company directories or running company-specific scripts, in a private repo. Then I put that repo as a submodule in my public repo. Anyone can look at or clone my public repo, but only I'll be able to initialize the submodule.


What do you mean by "the open"?

Mine are on Github, but in a private repo. They're nothing special at all - there are better examples for others to learn from.

As a backup, or for a refresh/new machine - what easier way than to clone my own repo? I guess I could them on another disk, a USB drive say, but will I really remember to plug it in to push changes? It would certainly be easier just to use Github.


> Mine are on Github, but in a private repo.

The fact that Amazon has paid engineers to write a bot that scans for API keys suggests that most people aren't that careful, or willing to spend $7/mo so they can use private repos. It sounds like you're doing it right, but most people seem to be doing it wrong.


> The fact that Amazon has paid engineers to write a bot that scans for API keys suggests that most people aren't that careful

The fact that GitHub has not paid engineers to write a bot that scans for API keys, RSA keys, and other common credentials mistakenly committed and dropping the files from UI view / search indices without notification and explicit permission surprises me a lot more. The company seems to be full of great engineers and UI people; doing something like this would vastly improve the UX of developers beginning to use the platform, and would likely not get in the way of seasoned ones.


The fact no one muss mentioned that Bitbucket provides Free Private Repos eliminating the "can't be bothered paying" aspect is amazing and it makes the question "why would you not just put them in a private git/hg repo, it's practically free backups!"


    > most people aren't ... willing to spend $7/mo so they
    > can use private repos
Ah. I'm a student, I forgot there was a fee normally.

Still, there's Bitbucket and others, or self-hosted if so inclined.


Just recommending "closed configuration"? Same disadvantages as closed source.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: