One of our customers reported a funny issue with the pre-lock.bat hook script. Yes, when he used Subversion Server on Windows system. The customer is using a custom pre-lock.bat script to explicitly lock the file before every commit.

Why does he explicitly lock the file while svn commit itself locks the file implicitly? He has a valid reason to do so.

In earlier releases (v1.6), Subversion discarded the stdout messages printed in hook scripts. It is applicable for all hook scripts including pre-lock.bat script. Starting with v1.6, it behaves the same with all hook scripts, except the pre-lock.bat script. The message printed in this hook script is used as a UID for the lock. It should be unique across the repository. The best part about Subversion is that it is clearly documented in the Subversion 1.6 Release Notes.

Guess what? The customer complained that the custom pre-lock.bat script worked very well in prior releases, but it do not work with Subversion 1.6. When he performed a file commit, he faced a 423 Locked Error error. We attempted to release the lock obtained by a different user, if any, using svnadmin rmlocks and svn unlock --force commands, but they did not help. When we investigated if it has to do with any stdout messages, we discovered that NO it didn't. The hook script does not print any message to stdout.

WHERE THE PROBLEM EXISTS?

The issue is that the customer has set echo on globally in his Windows system. It prints all the commands we execute in the hook script to stdout, including the comments as in rem command.

The solution is to set echo off in his system, and he no longer faces the problem!

When you use softwares which requires a username and password to be keyed in every time you access some resource, it becomes a pain. On the other hand if that software is capable of remembering your username and password, then it is a great advantage. But what if the username and password which is remembered by this software is stored in plaintext at some location in your system? Isn't it a security risk? Of course yes, specially when you don't know that your passwords are stored in plaintext. This was the case with subversion till 1.6.0, but now we have greater security improvements to subversion 1.6 which aids us with a lot of features to avoid such a scenario.

Warn caching of plaintext passwords

From the past subversion had capabilities of caching passwords, but in systems which does not have a good method of storing these passwords in encrypted form, subversion silently cached passwords in plaintext, which was bad, since the user is not aware of this fact, specially the new users of subversion. On one fine day when they come to know about this fact, they are disappointed. So we thought of solving this in the subversion community since this was a common problem reported by many users in the mailing list. Subversion 1.6 behaves in a different way when it is about to cache passwords in plaintext, as you can see from the following sample run,

 
 $ svn co http://localhost/svn/repos wc 
 Authentication realm: <http://localhost:80> TEST SVN repository 
 Password for 'stylesen': 
 ----------------------------------------------------------------------- 
 ATTENTION! Your password for authentication realm: 

 <http://localhost:80> TEST SVN repository 

 can only be stored to disk unencrypted! You are advised to configure 
 your system so that Subversion can store passwords encrypted, if 
 possible. See the documentation for details. 

 You can avoid future appearances of this warning by setting the value 
 of the 'store-plaintext-passwords' option to either 'yes' or 'no' in 
 '/home/stylesen/.subversion/servers'. 
 ----------------------------------------------------------------------- 
 Store password unencrypted (yes/no)? yes 
 Checked out revision 0. 
 $

Thus the user is aware that his password is cached in plaintext. What if the user decides not to store the passwords in plaintext, but don't want to get prompted each time? In such a case the user can play around with the following options in subversion servers file, ie., '~/.subversion/servers'

Globally,

 [global] 
 store-passwords = yes
 store-plaintext-passwords = yes

Per server basis, 

 [groups] 
 group1 = *.collab.net 
 othergroup = *.example.com
 
 [group1] 
 store-passwords = yes
 store-plaintext-passwords = yes
 [othergroup]
 store-passwords = no
 store-plaintext-passwords = yes 

Oh wait, all the above is specific to *NIX users, we already have mechanisms built in Subversion to cache passwords in encrypted form using wincrypt API in windows machines and Keychain services in Mac OS.

Okie, that is cool, but yet *NIX users like me are not happy, since we don't have a proper mechanism in place which stores passwords in an encrypted form. That is not true anymore, since 1.6 comes with support to cache passwords/passphrases in an encrypted form in GNOME Keyring or Kwallet depending upon the desktops they use. The password store could also be chosen with the following parameter in the subversion config file ie., '~/.subversion/config' as follows,

 [auth] 
 ### Set password stores used by Subversion. They should be 
 ### delimited by spaces or commas. The order of values determines 
 ### the order in which password stores are used. 
 ### Valid password stores: 
 ### gnome-keyring (Unix-like systems) 
 ### kwallet (Unix-like systems) 
 ### keychain (Mac OS X) 
 ### windows-cryptoapi (Windows) 
 password-stores = gnome-keyring , kwallet

GNOME Keyring

In order to enable Subversion to cache passwords in GNOME Keyring we need to pass the following parameter to the “configure” script while compiling Subversion source.

--with-gnome-keyring

The above requires GNOME Keyring libraries available in the operating system, failing which Subversion falls back to caching passwords unencrypted. Once you have Subversion binary compiled with GNOME Keyring support, the password is automatically cached in the Keyring, provided it is unlocked. CollabNet subversion binaries are compiled with GNOME Keyring support which you can use right away, to get this feature.

What if my GNOME Keyring is locked? Subversion provides a way to solve that too,

 $ svn co http://localhost/svn/repos wc 
 Password for 'default' GNOME keyring: 
 Authentication realm: <http://localhost:80> TEST SVN repository 
 Password for 'stylesen': 
 Checked out revision 0. 
 $ svn co http://localhost/svn/repos wc 
 Checked out revision 0. 
 $

KWallet

KDE users are not left alone, you can make use of KWallet in order to store passwords in encrypted form. In order to use KWallet the Subversion binaries must be compiled with the following option

 --with-kwallet

SSL client certificate passphrase caching

As we know, subversion was good at caching passwords, but it didn't had any mechanism to cache SSL client certificate passphrases, may be this was never thought, since the users were limited. The only way to avoid entering client certificate passphrases each time was to hard code it in the servers file with the parameter ssl-client-cert-pp, which is ugly! But now in 1.6 we use the same infrastructure as above to cache SSL client certificate passphrases.

 store-ssl-client-cert-pp = (yes/no )
 store-ssl-client-cert-pp-plaintext = (yes/no)

Aren't you curious to watch this in action? Here we go,

 $ svn co https://localhost/svn/repos wc 
 Authentication realm: https://localhost:443 
 Client certificate filename: /home/stylesen/stylesen.p12 
 Passphrase for '/home/stylesen/stylesen.p12': 
 ----------------------------------------------------------------------- 
 ATTENTION! Your passphrase for client certificate: 

  /home/stylesen/stylesen.p12 

 can only be stored to disk unencrypted! You are advised to configure 
 your system so that Subversion can store passphrase encrypted, if 
 possible. See the documentation for details. 

 You can avoid future appearances of this warning by setting the value 
 of the 'store-ssl-client-cert-pp-plaintext' option to either 'yes' or 
 'no' in '/home/stylesen/.subversion/servers'. 
 ----------------------------------------------------------------------- 
 Store passphrase unencrypted (yes/no)? yes 
 Checked out revision 0. 

Thus Subversion 1.6.x brings in lot of security improvements which enhances and gives a better user experience.