How big a security risk is the svn project checking right at the production site?

Question

Not that I did something like that, but I am interested in how bad this practice is.

Answer 1

Not if your server denies access to all .svn directories from the Internet.

Answer 2

I cannot comment on security-related risks, but this may lead you to a situation where unconfirmed / incompletely tested code enters the production environment. If you plan to use svn as a method for distributing the source in different environments (dev, testing, production, etc.), I would suggest you use the following approach:

You have a section of the tree in which the stable is stored (most likely a branch), and make it responsible as the gatekeeper for this branch. All fixations of the “stable” must go through them, and they will be responsible for making sure that nothing happens without verification. This position can be rotated weekly or monthly, if no one wants to do this for a very long time.

Alternatively, if you just want to dump adhoc periodically from subversion to production, you can use the "svn export" command.

Finally, I assume this is web development, if all you have to do is check to set up your production environment. If so, make sure that the user running the web server does not have read access to the .svn directories that store subversion metadata.

Answer 3

I do not consider this a security risk or bad practice. This is very convenient and something that I will probably do in future projects, of course.

As an example, Capistrano (an automatic rail deployment solution) is created around checking your code from SVN to your production servers.

There are some stupid things you could do that could make it a bad practice, but all of them are easily mitigated. For instance:

• Providing your svn repo on the Internet without password protection - Don’t do it!

• Providing your svn repo using http instead of https, so people sniffing your traffic can get your passwords. Again, do not do this! Just run it instead of https.

• Verify code with svn read / write account. Personally, I would not worry about this last step, as if they were compromising your production server, you have big problems, and you can simply just discard any changes that they might try to commit to svn. If you were extremely paranoid, you could just make an svn account just for production checks.

• Checking your trunk for production is only a problem, if you work with an unstable trunk, you can just check your stable branches / tags for deployment.

Answer 4

There are already great answers. But let me try to quantify the risks in some way.

Suppose that 2 months ago the risk of a trojan was small enough to be acceptable. In addition to the Kaminsky DNS, attacking and surpassing the risk of the Trojan just rose from a theoretical active attack on something in the “script kiddie” area. This is due to the fact that most public subversion projects use http or https, they do not use a certificate with a full chain of certificates. Then all that the adversary has to do is poison the DNS and clone the SVN server, it has its own trojan.

Answer 5

Well, if this code you are checking is basic (stable), I don't think this is a big problem.

But you must mark the code in order to later find out what you put there.

Answer 6

It is probably safer than a copy from the test server, at least you are sure that you are getting the correct version of all the files, and all the files are copied.

Answer 7

If we talk about the stability of an application (or code), there is always a risk during deployment.

But other than that, what is the security risk if you can use https rather than http. Or you even use an SSH gateway.

Answer 8

Here's how I would do it:

Assumption:

• Project under one root folder (Projectroot)
• All version control files

Actions

1 Make sure there is a label for the "new" production version
2 Check or export this tag to the projectroot.new folder
3 Stop the service
4 Rename projectroot.old <project <projectroot.new
5 Restart the service
6 If you need to step back, cancel step 4

Reasoning

This is done in order to make the actual steps of implementation and return as elementary as possible. You can simply use the svn switch, but any problems during cancellation can leave you with a broken system.

It is clear that this is the simplest case - not data transfer, not converted configuration files, etc .; but I think the key is to create a copy tree, then a replacement, to give you a clean, clear permutation and backup.

Answer 9

I don't necessarily like checking the repository directly for deployment. In particular, do you need every single file (e.g. test files) deployed for production? Also, will you have generated code at some point in the future? It is probably best to have a build system that creates a distribution kit for deployment.

However, instead of any of these solutions, be sure to record the revision of the repository that you are synchronizing. Thus, the synchronization is reproduced, and if an error occurs in the production that you cannot reproduce, you can synchronize your local repository with a state compatible with the production.

Answer 10

I find the use of SVN very convenient and reliable. We have a policy of maintaining a stable trunk and making non-critical changes in the branch lines, which later merge into the trunk shortly before the release date.

It makes it as simple as executing 'svn up' for small / less complex projects. Simplified deployment makes it easier for non-developers (sysadmin, on-call support, etc.) to quickly restore problematic changes if the appropriate developer is not available. In case of problems with the new version, it is just a matter of returning to the last known stable copy.

My only real problem is the visualization of SVN metadata. Make sure you configure the web server to deny access to the .svn directories (and all files contained inside). You can use svn export or delete SVN metadata as part of the release process: find. -name.svn -print0 | xargs -0 rm -rf

What you don't want is surfing at www.example.com/.svn/entries, which will open your source code repository, usernames and files. This is especially bad if you did stupid things like "passwords.conf" that can be read to users (depending on the server configuration), of course, this is not an SVN error. As mentioned in other answers, you also don't want to use HTTP.

In short, as long as your metadata and SVN repository are secure, I see no minuses, only benefits.