Subversion 1.6: Security Improvements Illustrated

Last month, while discussing some of the new and significant features available in Subversion 1.6, we talked a little bit about the security features. This month we’ll concentrate exclusively on security improvements.

Warning when passwords are cached in plain text

The Subversion client always had capabilities to cache passwords provided by the user in the ~/.subversion directory in *NIX systems. Unfortunately, these passwords were cached in plain text form, which the user is not explicitly intimated about. Subversion 1.6 throws a prompt before storing passwords in plain text if it is unable to locate a mechanism to encrypt passwords provided by the operating system. This is illustrated as follows:

$ 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.
$

The default behaviour is to prompt the user if passwords are going to be stored in plain text. If you don’t want to be prompted each time, then you can opt to specify this information in the Subversion servers configuration file, either globally or on a per-server basis, with the following parameters:

Globally,

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

Per server,

[groups]
group1 = *.collab.net
othergroup = *.example.com

[group1]
store-passwords = yes
store-plaintext-passwords = yes
[othergroup]
store-passwords = no
store-plaintext-passwords = yes

We already have mechanisms built in Subversion to cache passwords in encrypted form using the wincrypt API in Windows and Keychain services in Mac OS.

Caching SSL client certificate passphrases

The new version provides a way to cache SSL client certificate passphrases also. Previously, you had an option to specify the client certificate passphrase in the servers file, where you needed to hard-code the passphrase for each SSL client certificate with the parameter ssl-client-cert-pp. Now Subversion automatically caches this for each certificate. This feature is analogous to caching passwords, where you are prompted before storing the passphrases in plain text, as explained in the above section. You can also have control over the plain text passphrase caching with the following parameters in the Subversion servers file:

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

The following code illustrates caching of plain text passphrases:

$ 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.

Encrypted password/passphrase caching

Version 1.6 provides an easy way in which passwords/passphrases can be cached in an encrypted form in *NIX systems. If you are a GNOME user and want to store Subversion passwords in encrypted form, then you can use the GNOME Keyring to do so. KDE users can make use of KWallet. In order to use either of these, the Subversion binaries must be compiled with the option for GNOME Keyring or KWallet support. The password stores that must be used can be configured by specifying it in Subversion config at ~/.subversion/config.

[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

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 your operating system, failing which Subversion falls back to caching passwords unencrypted. Once you have Subversion binary code compiled with GNOME Keyring support, the passwords are automatically cached in Keyring, provided it is unlocked. If the GNOME Keyring is locked, you’ll get a prompt to unlock it. Once unlocked, the password will get stored in Keyring. A sample run is as follows:

$ 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.
$

KDE can also 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

Subversion is a widely used version control system in many free software projects and corporate environments. With its new features and improvements, users will benefit from the ease with which they can use it. The latest release (version 1.6.1) of the source can be downloaded from subversion.tigris.org. If you want Subversion binaries for different platforms, visit open.collab.net.

  • http://www.newtnotes.com JDS

    Hi. This is useful information, thanks!

    What about SVN on the command line? Has anyone had success getting gnome-keyring-daemon running in a CLI-only session (e.g. SSH session or whatever)

    I’ve been trying this on Solaris but I keep getting an error.

    > gnome-keyring-daemon

    ** (process:18063): WARNING **: unable to create keyring dir
    GNOME_KEYRING_SOCKET=/var/tmp/keyring-Qx8nxH/socket
    GNOME_KEYRING_PID=18063

    What dir is the gnome-keyring-daemon trying to create?

    This is probably the wrong forum for this question, but tia anyway.

  • YS

    Same here… Any ideas anyone. Environment is NIS mounted home directories and ssh using putty/cygwin .

  • http://www.stylesen.org Senthil Kumaran S

    The error says is all. When you start the gnome-keyring-daemon, it tries to create the socket and pid files in your systems tmp area. If the user do not have permissions to create these files in /tmp area, you will get such an error.

  • http://www.newtnotes.com JDS

    No permissions? This error I get when I run the command as root! Also, /var/tmp has open rw perms for all users.

    I seriously don’t think it is permissions.

    Any other ideas?

  • Christian Deutsch

    Thanks for this information, it looks very helpful. But how can I add a .p12 certificate to my gnome session keyring? I was not able to find an answer to this question yet. I have now set the config: [auth] option and the servers:ssl-pkcs11-provider line so this would hopefully be the last bit, when I have successfully added the certificate to the keyring, subversion (if it was built as you specified) might be able to automatically retrieve the certificate from the keyring, right?

  • Kurosu

    Using strace -f,  you can notice that it fails at opening ~/.gnome2/keyrings as a starter. Those are usually upon login through X and gnome2 session. Probably one needs to create ~/.gnome2 manually (verify the permissions there), and any missing subfolders the strace command may indicate.

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherwise noted.
Open Source For You is powered by WordPress, which gladly sits on top of a CentOS-based LEMP stack.

Creative Commons License.