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.
Please stop serving .git to the outside world
71–80 of 91 posts
Re: Please stop serving .git to the outside world
#72Re: Please stop serving .git to the outside world
#73Re: Please stop serving .git to the outside world
#74http://www.fcc.gov/.git/config FCC has a github account. http://www.fcc.gov/.git/logs/HEAD
Re: Please stop serving .git to the outside world
#75Re: Please stop serving .git to the outside world
#76You can keep the same workflow but just have .git somewhere else. Just define GIT_DIR.
Re: Please stop serving .git to the outside world
#77I 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…
To explain it briefly:
mv .git ../git-repo
echo "gitdir: ../git-repo" > .gitRe: Please stop serving .git to the outside world
#78Earlier 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.
Re: Please stop serving .git to the outside world
#79Earlier 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
Re: Please stop serving .git to the outside world
#80Earlier 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.
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).