Live data from Hacker News

Please stop serving .git to the outside world

pythonsweetness.tumblr.com

71–80 of 91 posts

Re: Please stop serving .git to the outside world

#71
post #30

Earlier quoted context omitted.

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.

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.

Re: Please stop serving .git to the outside world

#77
post #55

I feel incredible stupid asking this, but...how? I'm running a (very small) personal site on lighttpd, and updating it via git. I checked my.server.com/.git/config - and was duly served the config file. Eek! So I edited my /var/www/lighttpd/lighttpd.conf file, and added the following lines: $HTTP["url"] =~ ".git" { url.access-deny = ("") } and (I have used [asterisk] for the symbol, here, as otherwise it rendered my…

You can turn the .git directory in a simple "shortcut"

To explain it briefly:

  mv .git ../git-repo
  echo "gitdir: ../git-repo" > .git

Re: Please stop serving .git to the outside world

#78
post #30

Earlier quoted context omitted.

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.

Re: Please stop serving .git to the outside world

#79
post #16

Earlier quoted context omitted.

Why would it contain passwords?

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

Re: Please stop serving .git to the outside world

#80
post #30

Earlier quoted context omitted.

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.

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

Post reply on HN