Six weeks ago I blogged about the 2008 Product of the Year Award from developer.com and asked you to nominate Subversion to be part of the contest. Many readers must have followed up and Subversion is now a finalist in two categories.

Let's make sure Subversion wins, it deserves it. Please go to the voting page on developer.com and vote for Subversion in the categories of "Development Tool of the Year" and "Open Source Tool of the Year".

You'll see Subversion show up as "CollabNet Subversion", which is our distribution of Subversion. I do not know why that happened but I asked them to change it to "Subversion" to make sure the community at large gets credit for Subversion's success. Developer.com promised to take care of it.

The following instructions on how to change the SourceForge Enterprise Edition Download to support SSL connections to the Subversion repository are at your own risk and not supported by CollabNet.

If you are still eager to access your Subversion repositories via a secure connection on your SFEE Download machine: Read on!

Why do this?

As I wrote in my last post that concentrated on how to port Subversion 1.5-dev to SFEE, I love to work with SourceForge Enterprise Edition, which I use for my own projects. I like the fact that, with a single click, I can create a new Subversion repository to store code and documentation of my projects, and that the SFEE permission settings for every account are automatically applied to the Subversion server configuration, so I do not need to change config files on my own.

The free 15-user SourceForge Enterprise Edition Download does not come with preconfigured SSL support because CollabNet cannot export strong cryptography to every country. If you only host Open Source projects on SFEE and do not have to care about potential attacks that try to grab your Subversion and SFEE password, using SFEE and Subversion over the default HTTP-port is the most convenient and best performing option. However, if you like to access SFEE's Subversion repositories over a secured connection, this blog post explains how to implement that. The procedure is really straight forward and can be applied in almost the same time you need to read this blog entry.

Backup everything

Before proceeding with the next step, you should backup everything that is worth saving. It is very unlikely that the following steps will affect any of your data but you should play on the safe side.

Yum is your friend (again)

As in my last blog post, yum is the key to success. This time, you do not have to modify any configuration file but simply type:

yum install mod_ssl

in a root console on your VM-ware image. Confirm all questions with "yes" (make sure that the country you are live in allows you to use strong cryptography).

Yum automatically generates the config files for apache that are needed to support SSL and generates a self-signed certificate for your domain. Self-signed certificates will not be immediately accepted by your browser, so if you have the possibility to sign your certificate with your own one, please tell me and I can help you to change the certificate for SFEE. If you do not have your own certificate, do not worry, this does not reduce the level of security, but people that try to connect to your Subversion repositories will have to accept your certificate.

Now it is time to restart the webserver. Type:

etc/init.d/httpd restart

in a root console of your VM-ware image.

The only thing that remains between you and secure Subversion repository access are SFEE's firewall settings. To unblock the SSL port, simply type:

iptables -I RH-Firewall-1-INPUT -m state --state NEW -p tcp --destination-port 443 -j ACCEPT

in a root console of your VM-ware image. If you do not want to repeat this step after every reboot, you may add this configuration to a file that is read at every system start, like /etc/sysconfig/iptables

Now you are able to access all your Subversion repositories managed with SFEE over a secure SSL connection. Simply replace every Subversion repository URL that starts with http:// to start with https://

As you may have noticed, making Subversion accessible via a secure connection is only part of the game. Let me know if you are interested in a blog post or further documentation on either of these topics:

• Block insecure connections to SFEE and Subversion.
• Replace the self-signed certificate with a certificate that is immediately accepted by any Subversion client and browser.
• Configure the web-interface of SFEE to be accessible via SSL as well.

If you are, please post a comment to this blog post.