Deploying a Mercurial Repository to Production - Security Concerns and Tips

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.

Answer 2

Hi,

Other from the risk of the diff files being accidentally served to the client I don't see any other security concern.

Considering you restrict access to .svn, .hg or other. The fact that you have those folders there results in you having to constantly enforce the restriction to them, which is risky. Human errors do happen.

Regards, Alin

Answer 3

I'm a fan of having my DocumentRoot be a clone of my mercurial repository. Indeed, you can even configure that repo to automatically update on push using a hook like this:

[hooks]
changegroup = hg update

Which means that you can hg push to the repo on your server and you'll get the site checkout updated automatically. Quite a few folks are doing that.