On Mon, 21 Apr 2008, Stefan Sperling wrote:
> On Mon, Apr 21, 2008 at 01:46:52AM +0200, Martin Furter wrote:
>> 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?
Sorry that I didn't follow your work close enough...
That sounds good.
>> 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.
There are many users out there who never compile anything on their machine
because they just run "apt-get install" or similar commands. For those
distros it must be possible to separate the auth modules from the rest of
subversion. If they're not modules installing subversion would pull in all
dependecies like KDE, Gnome, etc. (or at least parts of them).
>> 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.
Yes, I know that. But it will somehow access the Gnome/KDE machinery which
can slow it down. My favorite test is "time xterm -e true" which needs
over one second on KDE though xterm is not a KDE application. With a sane
WM it just needs about 50ms.
>> 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.
Sounds interesting, I guess I have to read about that gpg-agent...
> 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.
A lightweight agent which is installed by default and available on every
machine would be nice, especially when working remote.
> One point I forgot:
>
> You are not defining "the problem" which should be solved.
>
> I don't know what problem you are thinking of exactly, but
> this is the problem I want to solve with the branch I'm
> working on (quoting myself from another mail in this thread):
>
> The goal is to make sure that as many people as possible are
> instantly made aware of how bad the current situation regarding
> password caching on Linux/*BSD really is the minute they start
> using Subversion, so they can act accordingly.
>
> The patch aims to help to achieve that particular goal, nothing else.
>
> This description about the problem is in isolation from all the
> new crypto stuff we're adding or planning to add, which will
> change the "current" situation quite a bit. But the plaintext
> case will not go away, so we need sane behaviour for it.
This will end the complaints "I found my password stored as plaintext".
But security dictators still can't disable the feature. Users are still
able to store the plaintext passwords but know they (maybe) know that they
do that. Have you ever seen a user not clicking "OK" if a browser asks him
if it should store his login and password?
I think moving all the auth stuff into modules has the following
advantages/disadvantages:
Advantages:
- Each module can be installed/enabled if needed.
- No 'hard' dependencies to other libraries.
- An API for adding more/custom auth modules.
Disadvantages:
- More complex code (maybe, could also make it easier to understand)
- More work.
There's also one thing I miss today: For some servers i don't want to
store passwords, for the rest I don't want to type it all the time...
I solved that by using different OS users which have store-auth-creds set
to yes/no in their configs.
(The reason I do that is that it forces me to think twice about committing
to those servers ;)
That is something i'd like to be able to configure per server.
Thanks for your good work. It's definitely a step in teh right direction :)
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-22 16:44:14 CEST