Hacker News Reader

Comment by drdaeman | Hacker News Reader

I think there's nothing wrong with this if there aren't (and weren't) any secrets directly embedded in the source code and all configuration files that contain sensitive information are (and always were) properly gitignore'd.

Tech-savvy users can even be encouraged to pull the code and send patches. :)

View on HN

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

Why would it contain passwords?

The history could. If you ever stored passwords in Git, even if you have now removed them, they would still be in the history.

Luckily, you can use git to rewrite history.

http://git-scm.com/book/ch6-4.html

Naive users have left passwords in by mistake, only to make another mistake in thinking a commit takes care of it.

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

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

Stop putting shit like this in your repo. Developers should not have access to credentials that make their way onto production.

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

Put them in deployment-specific configuration files.

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

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

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

Fortunately, it can be fixed just by changing your passwords, which you should do from time to time anyway.

Some people are naïve. All people make mistakes. And many people are naïve about whether they make mistakes.

Reply on news.ycombinator.com