CODEWITHSUNDEEP
phpweb-applicationsdeploymentmercurialsecurity
bitsoflogic
bitsoflogic

Reputation: 1224

Deploying a Mercurial Repository to Production - Security Concerns and Tips

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:

Alternatives are welcome.

Thanks!

Upvotes: 12

Views: 2319

Answers (3)

Wrikken
Wrikken

Reputation: 70460

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 their 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.

Upvotes: 8

Ry4an Brase
Ry4an Brase

Reputation: 78330

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.

Upvotes: 4

Alin P.
Alin P.

Reputation: 44346

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

Upvotes: 1

Related Questions