Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can't make SVN store passwords, even though the configuration is set to allow it

Tags:

svn

I did everything the book says, i.e. removed the authentication files from .subversion/auth, and explicitly set the relevant configuration parameters to 'yes' even though this is a default, and yet the shell SVN commands ask for a password each time. The repository is on cvsdude.com, and the client is Linux. I also use the Subclipse plugin that caches the password OK.

I vaguely remember that when I started working with it, the command asked interactively if I wanted to save clear password, and I said no. Can this choice be stored somewhere and take precedence over the configuration?

like image 844
davka Avatar asked Apr 08 '10 11:04

davka


People also ask

Where does SVN store passwords?

On Windows, the Subversion client stores passwords in the %APPDATA%/Subversion/auth/ directory.

Where is SVN password stored Linux?

On UNIX/Linux, there are no standard system encryption facilities, so the password is stored as text in ~/. subversion/auth/.


2 Answers

With recent versions of Subversion (~ 1.8) you can configure password caching via $HOME/.subversion/servers:

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

But depending on your system this may be not enough. If it is not, make sure that $HOME/.subversion/config contains:

[auth] password-stores = 

Which means that the variable password-stores is explicitly set to the empty string (background is that svn now contains support for some key-agent tools - and the interfacing to the default configured ones may be fragile - resulting in silent ignoring of the above options and non-caching behaviour).

When using svn for the first time, the hierachy $HOME/.subversion is created after the first svn operation - e.g. when doing the first checkout. Subversion creates then the mentioned files and fills them with the most important options - commented out, including some documentation.

Thus, it also makes sense to move an old $HOME/.subversion directory away to have a well-defined starting point.

Another pitfall are permissions - i.e. files which are not readable under $HOME/.subversion - but this should not often be the problem, because when svn creates them, it takes care of the right permissions (e.g. the auth directory is only readable by the user then, not by the group/all, independent of the configured umask).

like image 88
maxschlepzig Avatar answered Oct 05 '22 22:10

maxschlepzig


Veni

I believe I tried everything:

  • checked the server configuration
  • checked the ~/.subversion permissions, all 600
  • checked the ~/.subversion/config file
    • store-plaintext-passwords = yes
    • store-passwords = yes
    • store-auth-creds = yes
      • did the above both in the [global] and [groups] section with my username
  • checked the ~/.subversion/servers file
    • same as above

For all configuration files, I verified all sections, and also entered one wrong parameter and verified that the svn client stopped working (so, the config file was being read).

  • removed and re-created the ~/.subversion/auth directory

Checked that the client configuration in $HOME/.subversion/config disabled password stores:

[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. # password-stores = gpg-agent,gnome-keyring,kwallet ### To disable all password stores, use an empty list: password-stores = ### Both 'store-passwords' and 'store-auth-creds' can now be ### specified in the 'servers' file in your config directory ### and are documented there. Anything specified in this section ### is overridden by settings specified in the 'servers' file. store-passwords = yes    # just in case store-auth-creds = yes   # just in case 

Nothing worked.

Vidi

Then I read the fine manuals. Everything was copacetic: you are not expected to be able to do this. "On Unix systems, client-side storage of passwords in plaintext on disk is disabled by default at compile-time".

Vici

Fortunately, the part that reads the passwords is still there in the client binary. So, if the password happened to be stored, it would work. I am running SVN 1.13:

svn, version 1.13.0 (r1867053)    compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu 

So I opened the file just created in the ~/.subversion/auth/svn.simple directory (it may contain more than one file, you might need to inspect them to find the one with the realm you want) and found this content:

K 15 svn:realmstring V 37 <svn://home.sweet.home:3690> Profekto K 8 username V 6 lserni END 

The syntax is straightforward: "K" is the key followed by the length of the key, "V" is the value followed by the length of the value.

At the top of the file, I added by hand the eight lines that supply the plaintext password:

K 8 passtype V 6 simple K 8 password V 20 NotTheActualPassword 

(Note: on the latest Ubuntu, passtype is by default gpg-agent, and so my password gets overwritten. So I have to change "K 9 V gpg-agent" to "K 6 V simple").

and now it works.

like image 20
LSerni Avatar answered Oct 05 '22 20:10

LSerni