Re: [PATCH] don't store plain-text passwords by default

On Mon, Apr 21, 2008 at 01:46:52AM +0200, Martin Furter wrote:
>> I have never seen anyone post "please keep storing plain text passwords
>> by default at all costs." Someone has posted "I will tell svn to store
>> my password if this patch gets applied" to this thread. This is fine.
>> That's what the feature is for. If there's a concious decision involved,
>> the goal has been met.
>
> Please keep storing plain text passwords by default at all costs!
>
> You asked for it ;)

I did, yes :)
 
> I'm against another few quick hacks without a clean design.
>
> This "don't store plain-text" patch will just annoy the users and everyone
> will go back to the old behaviour. Additionally those loud security people
> will continue complaining because the problem isn't solved.

Have you checked the current status of the branch[1] that this
patch started off?

In short, the 'store-plaintext-passwords' option has three values now:
'yes', 'no', and 'prompt'.

'prompt' is the default and causes the following to happen:

  Password for 'harry':
  -----------------------------------------------------------------------
  ATTENTION! Your password is going to be stored to disk unencrypted!
  -----------------------------------------------------------------------
  You can get rid of this warning by editing your configuration file
  and setting 'store-plaintext-passwords' to either 'yes' or 'no'.
  Store password unencrypted (yes/no)?

If you type yes here, svn will save your password in plaintext and never
bother you again (for the same server and authentication realm).

Additionally, on the branch you can now (as of about half an hour ago)
specify the 'store-plaintext-passwords' option on a per-server basis
in the file ~/.subversion/servers. So you can set 'yes' to be the
default, but set 'no' for some servers, for example.

Is all this OK for you?

> Also people start adding other auth stuff like kwallet and I guess all of
> them pull in extra libs and add random calls into those libs which maybe
> popup windows and whatever.

Well, if you dont want popup windows from kwallet, don't run kwallet.

> I don't think anyone will distribute
> subversion binaries with any of those auth options enabled if it pulls in
> lots of unrelated libraries.

Well, on my system, I know that the port maintainer will simply make
all these compile-time options (and thus their dependencies) configurable
from a nice menu that pops up when I type
'cd /usr/ports/devel/subversion && make install'.
The menu will remember my preferences and never bother me again.

Other systems have their own ways of dealing with compile-time dependencies.
Compile-time dependencies are not exactly uncommon.

> And I fear it will have as awful startup times
> as other kde/gnome applications have.

There will be no noticeable overhead involved in this.

We're not converting Subversion into a KDE or Gnome application.
People who use gnome-keyring or kwallet support will be running KDE/Gnome
anyway, so the respective libraries will already be in RAM before Subversion
even starts running. It will just behave like any other application using
these services.

> I think all that stuff should go into loadable modules which can be enabled
> or disabled in /etc/subversion/config (or maybe a new file in there).
> Administrators will be able to choose which modules they install and which
> they don't because they're too 'insecure'.

This is a possible approach. But at the moment, making these things
compile-time options is easier for us. Let's first get the functionality
working before we start thinking about how exactly it should be
packaged with a release.

> An svn-agent like ssh-agent would also be a nice thing to have.

I plan to look into adding support for GPGME, i.e. GnuPG2 support.

GnuPG2 has a gpg-agent, which can also act as an ssh-agent, so you
don't need to run two separate agents for GPG and SSH.
This should be a viable option for people not using KDE/Gnome (like
myself), but it will require a PGP key (security always has a price).
Many people are using PGP anyway, though.

There is no plan for a standalone svn-agent as far as I know.
Also I don't think it's worth it given that with gnome-keyring,
kwallet, gpgme, and sane handling of the plaintext case, we'd already
be quite featureful and "secure". Also I think we should rather let
crypto experts write crypto software and use that, instead of applying
our version control expertise to implementing crypto software.

> Just my 2 cents.

Thanks :)

I hope I could calm your worries a bit.

[1] http://svn.collab.net/repos/svn/branches/dont-save-plaintext-passwords-by-default/

-- 
Stefan Sperling <stsp_at_elego.de>                    Software Monkey
 
German law requires the following banner :(
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                               CEO: Olaf Wagner
 
Store password unencrypted (yes/no)? No