SVN won't cache credentials

Question

I'm using the commandline svn client (version 1.6.12, from the Ubuntu repos) and I can't seem to get it to cache my user credentials. I'm trying to access an https svn repository (something along the lines of https://subversion.FAKE.com/PROJECT). My username for this repo is different from my local username.

Here's the auth section of ~/.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
### 
### The rest of this section in this file has been deprecated.
### Both 'store-passwords' and 'store-auth-creds' can now be
### specified in the 'servers' file in your config directory.
### Anything specified in this section is overridden by settings
### specified in the 'servers' file.
### 
### Set store-passwords to 'no' to avoid storing passwords in the 
### auth/ area of your config directory.  It defaults to 'yes',
### but Subversion will never save your password to disk in
### plaintext unless you tell it to (see the 'servers' file).
### Note that this option only prevents saving of *new* passwords;
### it doesn't invalidate existing passwords.  (To do that, remove
### the cache files by hand as described in the Subversion book.)
store-passwords = yes 
### Set store-auth-creds to 'no' to avoid storing any subversion
### credentials in the auth/ area of your config directory.
### It defaults to 'yes'.  Note that this option only prevents
### saving of *new* credentials;  it doesn't invalidate existing
### caches.  (To do that, remove the cache files by hand.)
store-auth-creds = yes 

And here's the global section of ~/.subversion/servers

[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = defaultproxy.whatever.com
# http-proxy-port = 7000
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# http-auth-types = basic;digest;negotiate
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
#
# Password / passphrase caching parameters:
store-passwords = yes
store-plaintext-passwords = no
store-auth-creds = yes
# store-ssl-client-cert-pp = no
# store-ssl-client-cert-pp-plaintext = no

The only changes I've made are to explicitly set a few options related to storing passwords. I've tried setting password-stores = gnome-keyring with no effect. Additionally, I deleted ~/.subversion/auth (as per some other threads) and it still hasn't been recreated by the svn client.

Any suggestions? How can I force SVN to store my credentials (either in ~/.subversion/auth or using the gnome-keyring, I don't care).

Answer 1

You have at least three choices

1. Setup ssh with no passwords (try this example)
2. Use the gnome-keyring (google search for 'svn gnome keyring password'). This typically boils down to editing your ~/.subversion/config file (password-stores = gnome-keyring and store-passwords = yes).
3. Store the password in plaintext.

To store the password in plaintext, first delete your ~/.subversion directory. This will delete any previously configured items such as server certs you've already accepted and any previously cached passwords. The next time svn is run it will recreate a 'blank' directory structure. Then run the svn command against your repository. You should see something similar to the following:

$> cd <project directory>
$> svn update
Error validating server certificate for 'https://...':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: ...
 - Valid: ...
 - Issuer: ...
 - Fingerprint: ...
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Password for 'your username': secret
-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

  <https://...> ...

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/.../.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes

NOTE!!! This will save your password in plaintext (quite unsecure) but it will also cache your password so you don't have to type it every time. Ultimately the password is stored in plaintext in ~/.subversion/auth/svn.simple/.

Answer 2

If all of the options mentioned are set correctly, perhaps the svn client is failing to write the credentials file due to permissions. I found this thread experiencing the same behavior, and permissions was the fix.

Answer 3

Configuration files for subversion exist in user area (your home directory ~/.subversion) and in system area (/etc/subversion), see http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1.1. If may copy "config" and "servers" files from the system files or edit them directly if you have administrator permissions.

The simplest, but not secure, solution is to let subversion cache credentials in a plain file. For that simply set store-passwords = yes and leave all other settings to be default (commented).

Storing passwords with gnome-keyring might not work, because the tool was not installed or the gnome-keyring-daemon is probably not running.