SVN password encryption

[Gabriela Gibson <ga...@gmail.com>]

Hi,

Could we make the svn password encrypted by default by setting the
 ./subversion/servers entry 'store-plaintext-passwords' to 'no'?

Currently, setting up password encryption requires digging through the
docs, and it's tempting, especially for casual users, to avoid that effort
by storing the password in clear text.  Whilst people shouldn't do that,
there is just so much software and so little time, and all too often, 'I'll
do that later' never happens.

Even if the user sets up password encryption, the previously created clear
text password will sit around until they realise this problem and find and
delete that file.

I think that making passwords encrypted by default and requiring work to be
'unsafe' is a good solution here.  Or maybe, the ability to store clear
text passwords ought to be removed all together.

Also, it might be an idea that once the password for a particular user is
changed from clear text to encrypted, that the corresponding clear text
file is automatically removed; and that people who upgrade their svn and
still use a clear text passwords are prompted with the offer of an
automatic fix that encrypts their current clear text passwords, and then
removes the old clear text files, but gives them a chance of making a note
in case they long forgotten their passwords.

What do you think?

regards,

Gabriela

-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: SVN password encryption

[Stefan Sperling <st...@elego.de>]

On Sat, May 24, 2014 at 01:08:12PM +0100, Gabriela Gibson wrote:
> Hi,
> 
> Could we make the svn password encrypted by default by setting the
>  ./subversion/servers entry 'store-plaintext-passwords' to 'no'?
> 
> Currently, setting up password encryption requires digging through the
> docs, and it's tempting, especially for casual users, to avoid that effort
> by storing the password in clear text.  Whilst people shouldn't do that,
> there is just so much software and so little time, and all too often, 'I'll
> do that later' never happens.
> 
> Even if the user sets up password encryption, the previously created clear
> text password will sit around until they realise this problem and find and
> delete that file.
> 
> I think that making passwords encrypted by default and requiring work to be
> 'unsafe' is a good solution here.  Or maybe, the ability to store clear
> text passwords ought to be removed all together.
> 
> Also, it might be an idea that once the password for a particular user is
> changed from clear text to encrypted, that the corresponding clear text
> file is automatically removed; and that people who upgrade their svn and
> still use a clear text passwords are prompted with the offer of an
> automatic fix that encrypts their current clear text passwords, and then
> removes the old clear text files, but gives them a chance of making a note
> in case they long forgotten their passwords.
> 
> What do you think?

Removing clear text passwords has become much easier with 'svn auth'.
I think svn should show the 'svn auth' command which would delete
the password when saving a password in cleartext:

"""
  Your password was saved in plaintext. To delete the password from disk, run:
    svn auth --remove svn.simple myusername http://svn.example.com/svn/myrepos
"""

Many users don't realise that they can configure password storage.
In some environments, one of the encrypted options will work as if
by magic, e.g. if users are logged into GNOME and have gnome-keyring
running. In many environments the password storage software is
installed but unused because it needs to be configured first.

How about we try making configuration of the "password-stores" option
interactive? Before saving a password, we could show a list of available
storage providers and indicate which ones are already working, and which
ones would require further configuration, and allow the user to choose
among them. The user won't be able to use a store which isn't configured,
but they'd be aware of the option and would perhaps configure gnome-keyring
or kwallet as appropriate.

Expanding on that, we could even try configuring the stores on behalf
of the user. This would be highly system-specific and hard to get right
on every system, but still worth looking into.