4 ms·
Somebody correct me if I'm wrong here, but doesn't the .git directory essentially contain the entire history of the repository? The history could easily contain
by wldlyinaccurate 13y ago
Somebody correct me if I'm wrong here, but doesn't the .git directory essentially contain the entire history of the repository? The history could easily contain sensitive information like passwords. It will contain names email addresses of contributors, too. Try it yourself: cat .git/logs/HEAD
- deleted 13y ago[deleted]
- tokenizerrr 13y agoWhy would it contain passwords?
- maw 13y agoSome people are naïve. All people make mistakes. And many people are naïve about whether they make mistakes.
- lucaspiller 13y agoThe history could. If you ever stored passwords in Git, even if you have now removed them, they would still be in the history.
- siddboots 13y agoLuckily, you can use git to rewrite history. http://git-scm.com/book/ch6-4.html http://git-scm.com/book/ch6-4.html
- DigitalJack 13y agoNaive users have left passwords in by mistake, only to make another mistake in thinking a commit takes care of it.
- krapp 13y agoI've done this, accidentally published my livejournal passwords on a project. Now I make certain that at the very least I have a folder covered by .gitignore in my local repo that contains any auth tokens or whatnot and I double check the history before pushing it anywhere.
- beaumartinez 13y agoWell, it could contain OAuth tokens for external services (eg Twitter), as well as secret tokens (used in Rails, Django for cookies). Worse still, they could be using passwords in an external service (eg, for a database) and have included those as well.
- stouset 13y agoStop putting shit like this in your repo. Developers should not have access to credentials that make their way onto production.
- beaumartinez 13y agoSo how else should they handle them? Assuming the repo is private, keeping keys in the repo is the most frictionless way to ensure everyone has everything set up correctly. Environment variables get annoying quickly if you ever need different ones for different projects, and if you create a shell script (or Vagrantfile) to do it for you, you're still keeping the keys in the repo.
- dllthomas 13y agoPut them in deployment-specific configuration files.
- marshray 13y ago> Assuming the repo is private Git is designed to facilitate sharing. Repos are a poor tool for managing secrets, especially intermixed with a general software project. Use something else for secrets. Ideally you would generate the secret on the same server on which it will be used and not move it over the network (except for a one-off backup).
- andrewflnr 13y agoGranted, that stuff shouldn't be in the repo, but some of us are both dev and ops, or just working on our personal site. Chill out.
- orng 13y ago//TODO replace password and username with user input password = "johnsmithAdminpass1234" username = "johnsmith01" login(username, password) If your test-DB is the same as your live one and username and password are real admin passwords, then you are in trouble. It's horrible and you shouldn't do this, but it happens. Edit: formatting
- dllthomas 13y agoFortunately, it can be fixed just by changing your passwords, which you should do from time to time anyway.
- deleted 13y ago[deleted]