trouble with stored passwords

Bug #462624 reported by Martin Lindhe on 2009-10-28
This bug affects 7 people
Affects Status Importance Assigned to Milestone
subversion (Ubuntu)

Bug Description

Binary package hint: subversion

I run a new install of Ubuntu Karmic on my home computer.

I have some svn repositories that i work with, which i have checked out to my home computer.

At home, on my current session everything is working correctly, and the login credentials have been stored.

So i can do a "svn update" without re-entering login credentials.

However, when I remote connect to my home computer and try to do "svn update" in the ssh shell,
i get the following message (some details has been censored):

username@home:/devel/web$ svn update project1
Authentication realm: <> svn
Password for 'username':
ATTENTION! Your password for authentication realm:

   <> svn

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
Store password unencrypted (yes/no)? no
At revision 1473.

I previously ran Jaunty and i did the same things, without this issue.

I googled the issue and couldnt find a solution, however this does seem related to recent changes in the subversion client to work with gnome-keyring somehow.

Haakon Nilsen (haakonn) wrote :

I can confirm this on a minimal karmic server.

Stefan Sperling (stsp) wrote :

This happens because Subversion is unable to connect to gnome keyring
when you log in remotely. If Subversion cannot connect to gnome keyring,
it falls back to storing passwords in plaintext (and asking you before doing so).
So this is not a bug since the software is working as expected.

To use the gnome keyring password store when logged in from remote,
you could start a new gnome-keyring-daemon in your remote login session.
Or try to connect to an already running gnome-keyring-daemon somehow,
this might also be possible (though I don't know how).

Martin Lindhe (martinlindhe) wrote :


Thanks for your explanation.
I have used this way of work in a couple of years and it worked fine until i upgraded to Ubuntu 9.10.

I expect this to work, since it used to. Now it no longer works.
So I would say this is a regression rather than "working as expected".

This issue didnt occur before subversion and gnome-keyring was integrated.

Come to think of it, can those be decoupled? Or am i required to have gnome installed just to use a command line utility like svn these days?

Antonio Arauzo-Azofra (arauzo) wrote :

Martin, according to Subversion FAQ <> it seems that Subversion only supports Gnome-keyring or kwallet, not with a command line utility. For security reasons from v1.6 subversion asks before storing passwords unencripted. Maybe you were previously storing passwords unencripted inadvertently? Then, this bug should be just a suggestion to Subversion upstream developers.

However, I have not been able to make Subversion work with

On a fresh Ubuntu 9.10 Server edition:
sudo apt-get install subversion gnome-keyring
eval "`gnome-keyring-daemon`"
svn update

This wrote the unencripted password advise. Maybe I am doing something wrong. :-?

On 2010-01-30 16:04, Antonio Arauzo-Azofra wrote:
> Martin, according to Subversion FAQ
> <> it seems
> that Subversion only supports Gnome-keyring or kwallet, not with a
> command line utility.

subversion _is_ a command line utility.

i think some well-intentioning devs have forgotten that people actually
do use commandline. I mean people actually do use a system without
gnome,kde, xorg and so on on them.

in this case, svn should of course function anyway.


Thomas Zehetbauer (realborg) wrote :

same problem here; even though because I am using screen the error message does not appear until after I abort svn by pressing ctrl-c. solved problem by doing "chmod 000 /usr/lib/gnome-keyring/gnome-keyring-ask".

unfortunately it seems to be the current spirit of ubuntu to break things that used to work for many years just for the sake of implementing a feature (gnome-keyring) that brings no advantages to the user. the list of files having mode 000 on my system is growing: hwclock, nautilus, console-kit-daemon, pulseaudio

I'm also having this problem. I'm not able to access the gnome-keyring from a remote session.

How can you do this?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in subversion (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers