Earlier quoted context omitted.
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.
Please stop serving .git to the outside world
31–40 of 91 posts
Re: Please stop serving .git to the outside world
#32To be clear (it wasn't mentioned explicitly in the blog post), but it's obviously what the author was referring to, this is about people who are deploying web sites with static content which is being managed via git.
Re: Please stop serving .git to the outside world
#33For simple static sites, I use a workflow very similar to this one[1]. It takes a minute or two to set up, but once it's all configured, you can deploy to your heart's content without ever worrying about exposing your .git directory to the world. [1] http://toroid.org/ams/git-website-howto
Always, and I mean always put your web content into a directory separate from the root of your .git archive. This is the easiest way to avoid all of these problems.
Rails calls this directory "public", but it could be whatever you want, so long as what's mounted on your web server is not the root.
Re: Please stop serving .git to the outside world
#34To be clear (it wasn't mentioned explicitly in the blog post), but it's obviously what the author was referring to, this is about people who are deploying web sites with static content which is being managed via git.
I'm curious, what security risk does static content could pose by serving the .git ?
Re: Please stop serving .git to the outside world
#35Earlier quoted context omitted.
Why would it contain passwords?
Naive users have left passwords in by mistake, only to make another mistake in thinking a commit takes care of it.
Re: Please stop serving .git to the outside world
#36Solution: run one or more automated security tools across your sites, before deploying them to public locations. If possible, automate this process, so it happens all the time. The tools won't catch everything, but they will catch something you didn't, some of the time. Testing is good practice with all software! Do it.
Re: Please stop serving .git to the outside world
#37To be clear (it wasn't mentioned explicitly in the blog post), but it's obviously what the author was referring to, this is about people who are deploying web sites with static content which is being managed via git.
I'm curious, what security risk does static content could pose by serving the .git ?
I know checking secrets into source code is already a bad practice, but accidental publication takes bad practice and makes it a security hole.
Re: Please stop serving .git to the outside world
#38For simple static sites, I use a workflow very similar to this one[1]. It takes a minute or two to set up, but once it's all configured, you can deploy to your heart's content without ever worrying about exposing your .git directory to the world. [1] http://toroid.org/ams/git-website-howto
No. Not this. index.html has no business being in the root of your project. Always, and I mean always put your web content into a directory separate from the root of your .git archive. This is the easiest way to avoid all of these problems. Rails calls this directory "public", but it could be whatever you want, so long as what's mounted on your web server is not the root.
* Parent talks about static pages, not about rails-ruby/php/python project.
But i get your point : If somehow somebody screw with servers config, there is a risk to expose your apps files & configs. You can follow parents advice but set your root path in apache/nginx config to /var/www/www.example.org/public instead of /var/www/www.example.org
Re: Please stop serving .git to the outside world
#39This is clearly Ops problem.
Re: Please stop serving .git to the outside world
#40OK, so I knew about this one before. But if you didn't, there's a better solution than just remembering it, which seems to be the gist of this post. Solution: run one or more automated security tools across your sites, before deploying them to public locations. If possible, automate this process, so it happens all the time . The tools won't catch everything, but they will catch something you didn't, some of the time.…