Question

In my research, I found some concern around deploying an online PHP application while leaving its “.hg” folder or “.svn” folders in place on the production server. Unfortunately, I was not able to find a clear explanation as to why this is a concern. I would like to better understand this security risk.

It seems to me that you don’t want these folders visible any more than you want the contents of the PHP files displayed. Wouldn’t the solution be to configure the web server to not serve the “.hg” directory? Does the security concern run deeper than this? I really don’t know. Your assistance with this is greatly appreciated!

If it is helpful, the reason I want to keep version control on the server’s production repository is the following:

• Faster deployment from Staging (vs. doing a fresh copy per deploy)
• Easy and fast rollback capability
• The ability to verify that production remains unchanged (via hg st)

Alternatives are welcome.

Thanks!

Answer 1

Indeed, if one could rely on not serving the .svn / .hg directories by default, it would be no problem. As it is, someone (newbee / new develop / experienced on on a bad day) makes a little change that destroys those settings, and as ‘nothing goes wrong’ does not notice that the protection is gone. Voilà, your source code open to the world, with possibly even stored passwords & secrets. It’s not that something will go wrong with the proper settings, it’s that with a minor, easily glossed over alteration, they could go wrong, so why not play it safe?

On a tightly controlled release process, I find it easier to export certain branches / tags to certain folders, and a switch to a newer branche / tag that has survived testing is just changing the document root from /path/project/release-123 to /path/project/release-124 (making it just as easy, maybe even quicker, to switch back to release-123 may the need be there). If you have a release process with more a stream of small changes & bugfixes, working with exports can indeed be a pain, but the added security is worth it in my opinion.

On development servers, everything is already filtered on (VPN-)IPs or certificates, so there I employ a checkout with ‘the latest & greatest` trunk version with the version control dirs without any problem.

edit:

Both Mercurial and Subversion nowadays keep there data in a single .hg/.svn dir in the top level. As one would normally make a checkout where most of the files are outside the document root (and the document root is likely a subdirectory further down), this is fine. Just make sure your version control directories are not in a reachable folder for the webserver inside the document root, and you can keep checkouts rather then exports there without much problems.