Subversion 1.4.5 was released today.  You can download the updated CollabNet Subversion binaries immediately.

Subversion 1.4.5 contains a fix for a security exploit on Windows clients. This exploit was discovered and reported by researchers at the Colorado Research Institute for Security and Privacy.

The only change from Subversion 1.4.4 is the patch for this security exploit.  Since the exploit only affects Windows clients, we decided to only release CollabNet Subversion 1.4.5 packages for Windows. There is no point for someone who is already running 1.4.4 on any other operating system to update to 1.4.5.

I am not going to give a lot of details about the exploit, you can find more information at various security reporting sites, such as CVE.  I will say that it was a legitimate exposure that made it possible for the Subversion client to write files outside the normal working copy.  That being said, there are a couple of points to make:

1. Creating the exploit requires commit access to the repository.  If you can trust the people who have write access to the repository, then you do not have too much to be concerned about. The keyword in that sentence is "trust". If you are checking out from a repository you cannot completely trust, such as on a public hosting service, then be careful and update to 1.4.5 first.
2. While the exploit itself is pretty easy to produce, it is also pretty difficult to use it in a way that would cause harm.
3. You can only create the exploit from a non-Windows platform.
4. There is nothing terribly secretive about the exploit.  If you send commit emails, or even just browse your repository using svn ls, this exploit would stand out as not normal.

If you are running a Subversion client on Windows, this would include the command line client as well as any graphical client such as TortoiseSVN or Subclipse, then you should definitely go ahead and install this version of Subversion.  I would recommend that users of earlier versions such as 1.3.2 or 1.2.3 also install this update immediately. The Subversion 1.4.5 client can talk to any 1.x version of the server, so there is no reason not to update your client (for compatibility: if you have the command line and a GUI client, update them both).

Subversion servers are not affected by this exploit.  That being said, a Windows server that uses the Subversion client in scripts would still be vulnerable and should be updated to 1.4.5.

Now that the Mac community at openCollabNet is providing complete, up-to-date installers for command-line Subversion, what about GUI access?  This is the Macintosh, after all!  There are, of course, several stand-alone GUI clients, a standard integration into Apple’s Xcode, and plugins for Eclipse, JDeveloper, NetBeans, and other applications, but what about basic Finder access?  Windows users have had TortoiseSVN for years, and another Tigris project, naughtysvn, is working toward similar capabilities for the Nautilus desktop environment on Linux.  Why not the Mac?

“Why not,” indeed!  Introducing SCPlugin: Subversion for the rest of OS X!

Over at tigris.org, the SCPlugin project has been working away steadily to bring you full Subversion capabilities as a plug-in to the Finder itself — your entire desktop is Subversion-enabled.  We’ve just released version 0.7, a beta release we believe is full-featured enough to support your day-to-day work. 

So, what’s an SCPlugin?

We add “badges” to all the Finder icons for files and directories that are under Subversion’s control.  The badges tell you the status of the file: freshly checked out, modified, in conflict, and so on.

We also extend the Finder “Contextual Menu” (you know … control-click or click-and-hold-for-a-real-long-time, or right-click if you have a multi-button mouse) to have Subversion commands.  The available commands are applied to the files and directories you have selected when you pop up the menu.

With this plug-in, your OS X Finder joins the world of Subversion.

Some technical notes: Works in OS X 10.3.9 and 10.4.x.  Uses Subversion 1.4.x (don’t mix with other clients still using Subversion 1.3.x).  This is a beta version: some things probably don’t work.  Join the users@scplugin.tigris.org mail list for help with problems or use notes.

Jack Repenning, CollabNet CTO and SCPlugin community lead

Here on openCollabNet we publish a graph that shows the adoption of Subversion on public Apache servers (actually: only those servers that report their mod_dav_svn module, Subversion). The raw data is published monthly by the Canadian security and on-line services consulting company E-Soft.

Last month Subversion reached 150,000 servers that report their Subversion module and the growth is spectacular. In August 2006 E-Soft reported 46,000 servers, a year over year growth of over 3x !!! From 2005 to 2006: same story, from 15,000 to 46,000.

The number only reflects a subset of the Subversion servers out there. There are lots of Apache servers that do not report their modules (I understand it is practice to no longer do so for security reasons). And then there are the instances of public Subversion servers that run svnserve and many more servers behind firewalls. So, the report shows the trend of the adoption of Subversion, the actual number is much higher.

Another interesting report to look at is from CIA.vc (not the government). This report covers commit messages of over 1,000 open source projects. Subversion blows all other systems away and it is clear that it has overtaken CVS by a stretch, at least according to this report.

How many developers using Subversion does this translate into? Of course it is impossible to give an absolute number but if you take an average of 5 developers on each of these servers that E-Soft reports, make an adjustment for other public servers, add some hard data on really big projects that we know about (like the Apache project), add the number of developers using Subversion as part of CollabNet’s platforms (we have hard data on that of course), add hosting services and make an estimate of corporate use, then it is fair to say that well over 2 million developers now use Subversion.

Subversion is unstoppable and certainly one of the most successful open source projects.

Terminology

To best discuss svnsync without getting confused, we should establish some common terminology before going any further:

• Master: The live read/write repository that will be mirrored via svnsync.
• Mirror: The read-only repository that is synchronized with the master via svnsync.

Overview

svnsync is a utility that became part of the standard Subversion offering when 1.4 was released and is described as a program that "provides all the functionality required for maintaining a read-only mirror of a Subversion repository." While understanding the purpose of svnsync based on it's documentation is simple, why would maintaining a mirror repository be important in the enterprise? With each Subversion implementation being different, there can be many reasons but there are a couple common reasons as to the importance of maintaining mirror repositories:

• Provide a backup repository: This can be beneficial for failover, soft-upgrade, etc.
• Provide a simple read-only repository: Some people want a simple way to provide read-only access to a repository. With svnsync, you can easily achieve this without maintaining authorization files and such. (For example: To maintain a community access point to a repository while using a different repository for the actual developer actions.)

These are just a couple examples but should give you an idea as to what value svnsync can provide. (For a more detailed explanation, please refer to the "Repository Maintenance" chapter of the "Version Control with Subversion" book.) While I could jump right in to script suggestions and examples, doing so would be a shame. To really understand why we are doing what we are, we should really understand how svnsync works. I will be brief in my explanation and then we will go into example scripts and suggestions you can apply in your Subversion implementation.

Understanding svnsync

The way svnsync works is actually pretty simple: Take revisions from one repository and "replay" them to another. This means that the mirror repository plays by the same rules as the master repository. The user account performing the actions against the mirror repository must have write access to that mirror repository. The "secret sauce" that makes svnsync work is due to Subversion maintaining the necessary metadata to know what needs to be synchronized in special revision properties on revision 0 of the mirror repository. That is it. That is how svnsync works and although it is easy to understand, to make svnsync work as designed, there are a few "rules" you need to be aware of. The following is a list of rules and/or best practices for using svnsync:

• The synchronizing user needs read/write access to the complete mirror repository.
• The synchronizing user needs to be able to modify certain revision properties.
• The mirror repository needs to be read-only for all users except the synchronizing user.
• Before you can synchronize a mirror repository with the master, the mirror repository needs to be at revision 0.

Now that we know what svnsync is and how it works and why it might be useful, let's learn how we can start synchronizing a mirror repository with our master repository using svnsync.

Implementing svnsync

The only real prerequisite for implementing svnsync is to have a repository that you want to mirror already created prior to starting this process. Once that is complete, you can follow the steps outlined below:

Step 1: Create Mirror Repository

svnadmin create MIRROR_REPO_PATH

Step 2: Make Mirror Repository Only Writable by Synchronizing User

To make the mirror repository only writable by the synchronizing user, which in our example will be "svnsync", we have a few options. One option is to use the authz functionality of Subversion with a default access rule like this:

[/]
* = r
svnsync = rw

The other option is to use the start-commit hook to check for the svnsync user. Here is an example, as a shell script:

#!/bin/sh

USER="$2"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may commit new revisions as this is a read-only, mirror repository." >&2
exit 1

Step 3: Make Mirror Repository Revision Properties Modifiable by Synchronizing User

To do this, we need to create a pre-revprop-change hook with something similar to the following example, as a shell script:

#!/bin/sh

USER="$3"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may change revision properties as this is a read-only, mirror repository."  >&2

exit 1

Step 4: Register Mirror Repository for Synchronization

Perform the following svnsync command on any system:

svnsync initialize URL_TO_MIRROR_REPO URL_TO_MASTER_REPO --username=svnsync --password=svnsyncpassword

If everything is configured properly, you should see some output like this:

Copied properties for revision 0.

Now that you have registered your mirror repository for synchronization with the master repository, we should go ahead and perform the initial synchronization so that the mirror and the master repository are synchronized.

Step 5: Perform Initial Synchronization

To make sure everything is ready and to perform the initial synchronization, on any system, perform the following:

svnsync synchronize URL_TO_MIRROR_REPO --username=svnsync --password=svnsyncpassword

If everything synchronized property, you should see some output similar to this:

Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
…

Step 6: Automate Synchronization with post-commit Hook

Now with the initial synchronization out of the way, all that needs to happen now is to write a script to be ran either as a scheduled process or as a post-commit hook to synchronize your mirror repository with the master repository. I suggest the post-commit option as it gives you the best chance of having a mirror repository as up-to-date as possible.  Here is an example hook that might be used on the master repository to synchronize a mirror repository as part of the post-commit hook.  As a shell script:

# Example for synchronizing one repository from the post-commit hook
#!/bin/sh
SVNSYNC=/usr/local/bin/svnsync
$SVNSYNC synchronize URL_TO_MIRROR_REPO --username=svnsync --password=svnsyncpassword &

exit 0

That is it. Once you have followed the steps outlined above, you should have a mirror repository that is kept up to date automatically when someone modifies the master repository. This also concludes our introduction to svnsync and how to implement it.