SVN Edge 5.0 Released – with Java 8 Support

May 18, 2015 Mark Phippard

I am pleased to announce the release and general availability of SVN Edge 5.0. Downloads for Windows, Linux and Solaris are available now. If you already have SVN Edge installed, you can update from within the application itself. Windows users should read on though.

The driver for this release was support for Java 8. Normally, new releases of Java are not that big a deal because Java has excellent backwards compatibility and code written and compiled for older versions generally works the same on newer versions. I’ve been working with Java since 1.1 and that has always been my experience. So we were caught by surprise when SVN Edge did not run on Java 8. SVN Edge is not really a Java app in the traditional sense as it is built atop the Groovy on Grails framework. The version of the Grails framework we were using did not run on Java 8, and at the time Java 8 was released there was only a beta version of a future Grails release with Java 8 support. This release became official a while later, but we then had the problem that we had to move our code base across several major releases of Grails in order to upgrade. We were intentionally staying on Grails 1.3.4 because the 2.0 release had significant compatibility changes and the benefits were not that compelling for us. Now, in order to support Java 8 we had to make the leap all the way to version 2.4.4. Anyway, this is just a long winded way of saying it took a while.

While we were in the process of doing this major upgrade of the application framework, we received confidential disclosure of several security vulnerabilities and other suggested security improvements that the application ought to make. This disclosure came from Security Consultant Oliver-Tobias Ripka, and we would like to extend our thanks to him for sharing this information as well as giving us time to correct the problems.

You can view the complete list of changes in this release, as well as all of the security-related fixes in the release notes.  I would like to call out a few of the improvements here as well though. First, in order to generally improve our security and to enable several of the suggested improvements we moved our security and authentication framework to Spring Security Framework. This allowed us to implement a more robust password hashing algorithm (bcrypt) as well as implement policies for stronger passwords and throttling of failed login attempts. For users that use internal users and Apache passwords, as opposed to LDAP, we also increased the security of those passwords to use bcrypt. We enabled strong security by default, but we also added a security.conf configuration file to allow users some control over these options. We also changed all of the forms in SVN Edge to carry one-time tokens to prevent attempts at Cross-Site Request Forgery (CSRF/XSRF) attacks.

We also made major changes to our database. We upgraded to a more recent version of HSQLDB and also made some changes to improve the reliability of the database. This is an in-memory database and over the years a very small number of users have run into corruption, probably after some kind of hard crash where the memory could not write back to disk. These have been rare and in most cases could be easily repaired. However, we wanted to make several improvements to try to further minimize the occurrence of these problems. Besides upgrading to a newer version, we also split our database into two. The most critical of our database information contains the configuration and users. This only changes when you change the configuration and the data is very small. However, we also store operational statistics and metrics in the database and these are larger and more volatile. They are also less critical, so we split these into a separate database which should reduce any chance of corruption. We also are leveraging a new feature of HSQLDB to take automatic backups of the database. So we now do this automatically every 12 hours to serve as a secondary backup that can be used to easily recover the database if needed.

Finally, we also made some changes to the Windows packaging. We now include Java as an embedded JRE so you no longer need to have Java installed on the system and expose the web browsers on the server to the possible vulnerabilities in the Java browser applet feature.  We also updated to the latest version of the libraries we use to run SVN Edge as a service. We were not aware of any bugs in this library but it did “officially” add support for Windows 8 and Windows 2012 so it seemed like a worthwhile upgrade. To take advantage of these changes, you must upgrade SVN Edge one time by using the latest Windows installer. You do not HAVE to do this. You can still update SVN Edge via the web UI. Doing so, simply will not change over to the embedded Java or the newer Windows service.

In addition to these changes we also picked up the most common bugs and feature requests that were in the backlog and of course we are including the latest released version of Apache, Subversion and OpenSSL etc. These are actually still the same version that were included in SVN Edge 4.0.14 since there have not been any updates since then.

A new major release of Subversion is on the near term horizon.  Subversion 1.9.0-RC1 was recently released which means the final GA release should be out in the next 4-6 weeks.  We will have a SVN Edge 5.1 or 5.2 release available sometime soon after which includes those binaries for all platforms.

 
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.

Previous Article
Drive Better Version Control Practices with CommitStream™
Drive Better Version Control Practices with CommitStream™

We’re very excited to announce the general release of CommitStream™. Initially released in limited beta in ...

Next Article
Improving Agile Portfolio Management Coordination
Improving Agile Portfolio Management Coordination

Simply producing status reports in an enterprise with hundreds of software development teams isn’t enough t...