Can't make SVN store passwords, even though th

问题:

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?

回答1:

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

回答2:

I would like to submit a detailed answer in case it helps someone in future.

Subversion 1.6 and later will cache your username and password by default however it will not cache the passwords in plaintext unless you explicitly allow it via the command line or by changing the Subversion configuration.

If you checked out a working copy using the --username and --password options you will see the following message:

-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

<https://subversion.assembla.com:443> Assembla Restricted Area

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

So as mentioned in the message, subversion will only save the password unencrypted if you enter 'yes'. If you do so then you should not need to add the --username or --password options when performing svn commands in future.

However, if you prefer not to see this prompt at all you can change the global configuration for your Subversion client by changing the configuration file called "server" on your local machine. It is stored here:

~/.subversion/server

You will need to add the following lines to the "server" file:

[global]
store-plaintext-passwords = yes

With this change, you only need to perform an svn command using the --username and --password options once. Then Subversion will automatically save your credentials without the above prompt.

For more information on disabling this warning about caching passwords in plain text see the Subversion 1.6 Security Improvements blog post.

回答3:

I ran into this same issue, and believe I set all the appropriate configs in .subversion/servers and .subversion/config, too, tried removing .subversion/auth, etc., but to no avail.

I ended up saving the credentials by moving the .subversion directory (or removing it would work too) and running svn co. I got the following message:

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <http://sweeney:80> Subversion 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/davids/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? 

I typed yes, and then got the same message. Stubbornly, I typed yes again. Now my password seems to be saved.

Somewhat surprisingly, looking at the configs in .subversion, none of the settings are uncommented; they're all set to the defaults, so I imagine I would have to answer this warning twice to save a password for a different server in the future.

Hope this helps.

回答4:

I think I've found a helpful hint here: http://svn.haxx.se/users/archive-2013-07/0094.shtml

As I understood, the client forgot to check if a "gpg-agent" is currently running.

It is inserting the "passtype" = "gpg-agent" into the ~/.subversion/auth/svn.simple/-cache-files by default.

That is a mistake!

As a solution (and to avoid to alter the password-cachefiles in ~./subversion/auth/svn.simple/ by hand) remove these file (but make a save-copy).

Add the line, into ~/.subversion/config ([auth]-section):

password-stores=

(CONSIDER: the empty value! This prevents the client from choosing any wrong stuff and assume "simple".)

Now e.g. try a:

svn up

Subversion will now warn you to save plain passwords.

If you got no problem with that, type "yes" and all is fine again.

After that, Subversion has created a cache-file for a particular server, and you can remove the "password-stores"-entry again.

回答5:

Delete old stored password like rm ~/.subversion/auth/svn.simple/*. I have tried every other suggestion and this is what worked for me.

回答6:

Thanks to your comments I found the problem - it's the settings in the servers file (don't store plain passwords). I wonder why there is this redundancy with the [auth] section of the configuration file. The SVN book also does not mention this when talking about storing passwords.

回答7:

I needed to make to changes to the server file to make this work for me

# Password / passphrase caching parameters:
store-passwords = yes
store-plaintext-passwords = yes

回答8:

You may use the gnome-keyring even without X inited. You should run

export `gnome-keyring-daemon`

on login and

kill $GNOME_KEYRING_PID

before logout.

Then you can use keyring_tool commandline utility.

回答9:

On Windows with slikSVN, I was having the same issue, but only with one of the projects, so I went in %AppData%\Roaming\Subversion\auth\svn.simple and deleted the file containing that project information.

The next SVN command I typed asked for the password and created the file again and now it's running great.

Maybe the fact I changed configuration and servers files helped too, but it was not working till I deleted that file (and it was working also with the previous configuration till there was a password issue on the server and the administrator reset permissions).

回答10:

If you are trying to reset the authentication on an existing working copy, I'd recommend you checkout a fresh copy after you do all of the above changes. This was the only thing that worked for me when I was trying to release the project with the maven-release-plugin (which uses stored svn credentials in order to auto commit your tags, etc...)

回答11:

Please be aware that there is a difference behaviour related to the password storing between a svn co/up and a svn log!

I tried all of the hints above and alway tried to verify with 'svn log' -- the svn command always asked me again and again for password, no matter if store-plaintext-passwords was set correctly to ask or yes. But when I made a new checkout or update I suddenly had the correct behaviour and my password got save

I assume this is a bug to subversion to have different handling of password storing for the different commands -- at least I read no where about that before.

回答12:

For some odd reason, my .subversion folder was not owned by me and SVN wouldn't save certificates of passwords.

I just did a sudo chown -R me ~/.subversion and now everything works!

回答13:

I experienced such problems after a password change and cured it deleting the SVN configuration (and thus recreating it from scratch).

回答14:

Delete files from the below directory:

For Windows:

For example:

C:\Users\abcd.xyz\AppData\Roaming\Subversion\auth\svn.simple

abcd.xyz-->username

Note: Delete all files. These files contain meta data about the checkout. The next time when you store your password it will automatically create a file here.

Delete the .keyring file from your STS/Eclipse installation. Stop Eclipse and delete the file.

For example:

D:\Executables\New STS\STS-3.5.0-e4.3.2-win64\configuration\org.eclipse.core.runtime -->.keyring

回答15:

A solution that worked for me (even isnt' the better solution, at least bailed me out), it's to grant my local user all permissions to ~/.subversion directory and subdirectorys. Then i could do operations on subversion fast without prompt username and password.

回答16:

From what I read in the previous answers, none of these worked. What I found to work for me could be a combination of things or this final step which is to open the keychain app, find the key in question.

Right-click and go to "get info". Click access control section on the top. Then click the "Allow all applications to access this item". Although this might do something unintended.

回答17:

Nothing worked for me, no matter what I've done. I checked all possible options, config files and hundred pages in google about this problem. Eventually I gave up and just put this into my .bashrc

alias svn='svn --password <mypassword>'

回答18:

Since SVN 1.12 (April 2019), you basically can't. From the Release Notes:

On Unix-like systems, client-side storage of passwords in plaintext on disk is now disabled by default at compile-time. Password caching mechanisms based on Gnome Keyring, Kwallet, or GPG-Agent, are recommended instead.

This change does not affect Windows or Mac OS platforms, where passwords have always been stored in an encrypted representation.

So... unless you compiled your own SVN client, you now most probably have a version that does not allow plaintext passwords to be stored.

By the way, your previously working plaintext password may even stop working after a Subversion upgrade.

If you don't bother entering the password once per session, using gpg-agent is quite easy, though. Just start it with gpg-agent --daemon, run your svn command entering the password, and the next command won't request it anymore.