Subversion 1.6 Security Improvements

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 = yesPer 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.

svn 1.6 Subversion 1.6 Security Improvements


svn 1.6 network Subversion 1.6 Security Improvements

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.

Posted in Subversion
13 comments on “Subversion 1.6 Security Improvements
  1. A cool feature of the gnome-keyring support that you forgot to mention is that it can even be used when there is no X environment available, such as when logged into a remote SSH terminal session. In this environment, you need to manually start the gnome-keyring:
    $ export `gnome-keyring-daemon`
    This command can be run from the terminal or in your login script. Before exiting the terminal, or in a logout script you should run:
    $ kill $GNOME_KEYRING_PID
    CollabNet also provides a command line tool in the CollabNet Subversion RPM for creating and working with your keyring:
    $ keyring_tool
    Keyring tools is application that lets you manage keyrings.
    Usage:
    keyring_tool {–list | -t}
    List all the existing keyring names.
    keyring_tool {–setdef=keyring_name | -s keyring_name}
    Set given keyring as default keyring.
    keyring_tool {–getdef | -g}
    Get keyring name of default keyring.
    keyring_tool {–create=keyring_name | -c keyring_name} [-p password]
    Create a given keyring with a password.
    keyring_tool {–delete=keyring_name | -d keyring_name}
    Delete a given keyring.
    keyring_tool {–lock=keyring_name | -l keyring_name}
    Lock a given keyring.
    keyring_tool {–unlock=keyring_name | -u keyring_name} [-p password]
    Unlock given keyring with a password.
    keyring_tool {–modify=keyring_name | -m keyring_name} [-p password] [-n new_password]
    Modify given keyring, old password with a new password.
    keyring_tool {–info=keyring_name | -i keyring_name}
    Get information of a given keyring.
    keyring_tool {–version | -v}
    print version information.
    keyring_tool {–help | -h}
    Print this help.

  2. Dan Levine says:

    Thanks for the info. One question though: what if one has a need for automated builds with a pseudo user. Take the CruiseControl capability for example. Having the password cached is necessary, but one doesn’t want user-interaction (for opening the keyring).
    Does opening the keyring expose credentials in its unencrypted form? If not, then I guess opening that up under script control would be no big deal. But my guess is it is a big deal and should not be done.

  3. Dan Levine, For cruise control, you can open the pseudo user account once and cache the credentials in the keyring, further attempts will take it from the keyring. If you don’t want keyring at all, make use of the ‘–non-interactive’ option.
    We can see the credentials in the unencrypted form, in the gnome-keyring-manager. You can make use of the gnome-keyring APIs in order to get the credentials, but again this is specific to the user and tightly bound with the permissions of the user.

  4. antoine says:

    Is the collabnet version of the subversion client contain support for the gnome-keyring or would I have to compile subversion from source code? Also which version of the gnome-keyring should work with subversion 1.6 ?

  5. antoine, CollabNet Subversion has support for GNOME Keyring, you need not build
    subversion from source if you opt to use CollabNet Subversion rpm (> 1.6.x).
    GNOME Keyring version > 0.6.0 (which I used in my Debian etch box during
    development) should work with subversion 1.6

  6. antoine says:

    Hello all,
    If the password of the user changed, would the user have to use the keyring_tool to change the password? I was just wondering if the svn client could handle this on it’s own

  7. Hey..I love you blog. As you have very useful information with. Password is very important thing in our life as now a days we need a password for operating in bank account, We need password for mailing or chatting with friend. It plays important role in our life.

  8. So you need to build from the source in order to save password? That isn’t what you could call user-friendly…

  9. So you need to build from the source in order to save password? That isnt what you could call user-friendly…
    This may not be true always. If you have the latest subversion updates supplied by your operating system, then you need not build it from scratch.

  10. keyrings says:

    This blog rocks! I gotta say, that I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say I’m glad I found your blog. Thanks,

  11. njw-apl says:

    Hi Senthil,
    I’m trying to get svn and gnome-keyring working with CruiseControl too. I don’t understand your advice to Dan Levine, though. What do you mean by “open the pseudo user account once and cache the credentials in the keyring”? And if a password is necessary, how could the –non-interactive option work?
    I can use the gnome-keyring with svn by itself perfectly. It doesn’t ask for passwords. But then when CruiseControl tries to svn update it errors out because it couldn’t authenticate. The error is
    svn: OPTIONS of ‘repo url’: authorization failed: Could not authenticate to server: rejected Basic Challenge (host)
    Any idea what could be wrong? Thanks!

  12. Hello njw-apl,
    The error says, when the server challenges for a password it does not get one, which is apt for the user. This is because the password is not cached in GNOME-Keyring or there is no password available when the server challenges.
    My suggestion to cache the pseudo user password is simple. Identify the user which cruise control uses to talk with the subversion server and then do a ‘svn ls’ on the URL of the subversion repository with the same user that cruise control uses, if GNOME Keyring prompts for a password for this user, then cache it, then see to it that cruise control uses this user whose password is cached manually by you as described above. This should solve the problem, for future runs of cruise control.
    If you plan not to use GNOME Keyring, then you can make use of ‘–non-interactive’ option, but in this case you need to provide the username and password explicitly with the help of ‘–username’ and ‘–password’ options in the command line where you invoke the subversion binary.

  13. rooferkane says:

    This post is very informative. Hope people with such knowledge as you continues to share it. I’ll bookmark this for reference. All Tex Exteriors

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
   Contact Us
sign up for emails
looking for something
conversations

CollabNet: Ask the #Agile Guru questions related to Agile cultural shift, management best practices, engineering best practices http://t.co/optUVe9Rmj
Date: 15 September 2014 | 8:30 pm

CollabNet: Our Certified #ScrumMaster course is coming to NOLA on Sept 29-30! Don't miss out & register today! http://t.co/YXwZc1Lyux
Date: 15 September 2014 | 7:25 pm

CollabNet: Join #CollabNet Founder & CEO @billportelli: as he discusses his #Agile Journey Through Japan in today's blog! http://t.co/PzyCsNF6G9
Date: 15 September 2014 | 6:00 pm