Earlier quoted context omitted.
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.
Please stop serving .git to the outside world
21–30 of 91 posts
Re: Please stop serving .git to the outside world
#22.git should never be in your web root... I can't think of any situation (other than a very simple site) where you'd want to just stick the whole Git repository in the web root. Normally there's a bunch of other things in the repository (documentation, database scripts, etc.) that you wouldn't want exposed publicly.
You can hide it very easily with any of the virtual host syntax, and it's easy to deploy that way. I say, why not.
Re: Please stop serving .git to the outside world
#23This is clearly Ops problem.
Re: Please stop serving .git to the outside world
#24I recently discovered that I had been serving .git on my blog for a couple of years. All it took to fix was a simple rule in my Nginx config: # Don't expose hidden files to the web location ~ /\. { return 404; }
Yep. It's good practice to disallow . files because one time you may forget you put one there.
Re: Please stop serving .git to the outside world
#25I 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. :)
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]
Re: Please stop serving .git to the outside world
#26You can keep the same workflow but just have .git somewhere else. Just define GIT_DIR.
Re: Please stop serving .git to the outside world
#27.git should never be in your web root... I can't think of any situation (other than a very simple site) where you'd want to just stick the whole Git repository in the web root. Normally there's a bunch of other things in the repository (documentation, database scripts, etc.) that you wouldn't want exposed publicly.
You can hide it very easily with any of the virtual host syntax, and it's easy to deploy that way. I say, why not.
Because of all the reasons parent mentioned.
Re: Please stop serving .git to the outside world
#28I recently discovered that I had been serving .git on my blog for a couple of years. All it took to fix was a simple rule in my Nginx config: # Don't expose hidden files to the web location ~ /\. { return 404; }
Though, keep in mind the potential conflict with /.well-known/ - " rel="nofollow">http://tools.ietf.org/html/rfc5785>.
Re: Please stop serving .git to the outside world
#29.git should never be in your web root... I can't think of any situation (other than a very simple site) where you'd want to just stick the whole Git repository in the web root. Normally there's a bunch of other things in the repository (documentation, database scripts, etc.) that you wouldn't want exposed publicly.
You can hide it very easily with any of the virtual host syntax, and it's easy to deploy that way. I say, why not.
You could also very easily add one additional command to your deploy script to copy all the web content from the directory being pulled to to the web root, and not have to worry about any accidents.
Re: Please stop serving .git to the outside world
#30Earlier quoted context omitted.
Why would it contain passwords?
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.