How big of a security risk is checking out an svn project right into production site?

Question

Not that I'm doing something like that, but I am kind of interested how bad a practice like that is.

Answer 1

Well, if this code you are checking out is baselined(stable) I don't think is much of a problem.

But you certainly should tag the code, so you know later what you put there.

Answer 2

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

Answer 3

If we are talking about application stability (or code), there is always a risk during deployment.

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

Answer 4

I can't necessarily comment on the security risks involved, but it could put you in a situation where unvetted/not fully tested code ends up getting into the production environment. If you're considering using svn as method for distributing the source into different environments (dev,testing,production,etc), I'd suggest you take the following approach:

Have a section of the tree that's kept stable (most likely a branch), and make it someone's responsibility as a gate keeper to that branch. All commits to 'stable' will have to go through them and they will be responsible with making sure nothing goes in without verification. This position can be rotated on a weekly or monthly basis if no one wants to do it for very long.

Also, if you just want to do an adhoc dump from subversion to production periodically then you can use the 'svn export' command.

Finally, I'm guessing that this is web development if all you need to do is checkout to setup a production environment. If this is the case then make sure the user that the web server runs under does not have read access on the '.svn' directories storing the subversion metadata.

Answer 5

None as long as your server forbids access to all .svn directories from the web.

Answer 6

I don't consider it to be a security risk or bad practice at all. It's hugely convenient and something I'd probably do in future projects as a matter of course.

As an example, Capistrano (a rails automated deployment solution) is built around checking your code out from SVN onto your production servers.

There are some dumb things you could do which might make it a bad practice, but they are all easily mitigated. For example:

1. Exposing your svn repo to the web with no password protection - Don't do this!

2. Exposing your svn repo using http instead of https, so people sniffing your traffic can get your passwords - Again, don't do this! Just run it over https instead.

3. Checking your code out using an account with svn read/write access. Personally I wouldn't worry about this last step, as if they compromise your production server you have bigger problems, and you can easily just roll back whatever changes they may try to commit to svn. If you were extremely paranoid you could just make a readonly svn account for production checkouts.

4. Checking out your trunk to production - This is only an issue if you run with an unstable trunk, you can just check out your stable branches/tags for deployment instead.

Answer 7

Here's how I'd do it:

Assumptions:

• Project under a single root folder (projectroot)
• All files under version control

Steps

1 Ensure there's a tag for the "new" production version
2 Check out or export that tag into folder projectroot.new
3 Stop the service
4 Rename projectroot.old << projectroot << projectroot.new
5 Restart the service
6 If you need to fall back, reverse step 4

Reasoning

This is to make the actual implementation and fallback steps as elementary as possible. You could simply use svn switch, but any problems when falling back could leave you with a broken system.

Clearly this is the simplest possible case - no migration of data, no unversioned config files, and so on; but I think the key is in building a copy tree then swapping to give you a clean crisp switchover and fallback.

Answer 8

I don't necessarily like the idea of checking out a repository directly to deployment. Specifically, do you need every single file (like testcases) deployed to production? Also, will you at somepoint in the future have any generated code? Its probably better to have a build system that builds a distribution to deploy.

However, in lieu of any of those decisions, make sure you write down the revision of the repository you are syncing. This way, the sync is reproduceable, and if a bug comes up in production that you cannot reproduce, you can sync your local repository back to a state where it is consistent with production.

Answer 9

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

Suppose that 2 months ago, the risk of a trojan were small enough to be acceptable. Along comes Kaminsky's DNS attack and presto the risk of a trojan just went up from a theoretical active attack to something in the "script kiddie" realm. This is because most public subversion projects either use http or if https, they don't use a certificate with full cert chain. Then all an adversary needs to do is poison the DNS and clone the SVN server, with there own trojan.

Answer 10

I find using SVN highly convenient and reliable. We have a policy of keeping trunk stable and making non-critical changes in branches, which are later merged into trunk shortly prior to a release date.

It makes releasing as simple as executing 'svn up' for smaller/less complex projects. Simplifying deployment makes it easier for non-developers (sysadmin, on-call support, et al) to quickly revert problematic changes in the event that the relevant developer is not available. In the event of trouble with a new release it's simply a matter of rolling back to the last known stable copy.

My only real concern would be visiblity of SVN metadata. Be sure that you've setup your web server to deny access to .svn directories (and all files contained within). You could use svn export, or delete the SVN metadata as part of your release process: find . -name .svn -print0 | xargs -0 rm -rf

What you don't want is someone surfing to www.example.com/.svn/entries which would reveal your source code repository, usernames and files. This is particularly bad if you've done silly things like "passwords.conf" which may readable to users (depending on server configuration), of course, that's not really the fault of SVN. As mentioned in other answers, you don't want to use HTTP either.

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