12

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

joek1010
  • 141
  • 1
  • 1
  • 6

7 Answers7

8

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

cyber-monk
  • 5,470
  • 6
  • 33
  • 42
5

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.

user1810632
  • 51
  • 1
  • 1
2

For people coming back to this question;

On Linux like systems, storing of plain text passwords is disabled at compile time on versions 1.12 and later.

To force enable it (whilst understanding the security implications), you can do the following:

  1. In the ~/.subversion/servers file, you can enable storing of credentials with:

    store-auth-creds = yes

  2. Then you can run an apache python script to forcefully save your credentials as plaintext in cache: apache faq.html#plaintext-passwords

Sempai
  • 63
  • 9
  • The `store-auth-creds = yes` seem to be irrelevant, the `store-plaintext-password.py` just [worked for me](https://stackoverflow.com/a/74521736/1032586) without any changes to either `~/.subversion/servers` or `~/.subversion/config`. – Igor Nov 21 '22 at 16:11
  • Yes, this. This is the answer I was looking for. I was going crazy because none of my configuration changes were working. Thank you! – Gogeta70 Aug 04 '23 at 20:12
1

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.

Ilia Barahovsky
  • 10,158
  • 8
  • 41
  • 52
  • Thanks for the response, but unfortunately it didn't work. I tried setting only `store-passwords = yes`, and nothing happened (auth directory was still not recreated). I even tried setting `store-plaintext-passwords = yes`, and still no dice. I set all of these options in both /etc/subversion/* and ~/.subversion/* – joek1010 Mar 01 '11 at 04:15
0

Not sure if you are still looking for an answer here; but the option "ssl-client-cert-password" is probably the one you are looking for.

ssl-client-cert-password=<password>
Suroot
  • 4,315
  • 1
  • 22
  • 28
0

Don't know whether this has been solved yet, but have you tried adding 

password-stores =

to your 'config' file?

dstibbe
  • 1,589
  • 18
  • 33
0

In your configuration there is an option store-plaintext-passwords = no, which disallows storing the password in $HOME/.subversion unless there is some supported encryption available.

To revert to the pre 1.6 behavior you can change the value to yes, which allows saving the password.

Bert Huijben
  • 19,525
  • 4
  • 57
  • 73