[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion password encryption

From: <Maurice.Meyer_at_wellsfargo.com>
Date: Mon, 25 Jun 2012 16:04:04 -0500

Mark,

Thanks for the quick reply. That confirmed my suspicions that the current UNIX encryption mechanisms are really just Gnome and KDE (GPG seems to be memory-resident which isn't quite enough for our needs.) The built-in Encryption mentioned at the end of the document sounds very encouraging. Hopefully that will get some momentum.

What I've done here is to slightly modify the use of Gnome so that users don't restart the Gnome/dbus processes every time they login. This mitigates some of the issues with users managing these processes. Not ideal but a little better than stop/starting Gnome all the time and provides the ability for cron jobs to connect to an already runing Gnome process with no password prompt.

Thanks again,

Maurice

-----Original Message-----
From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: Monday, June 25, 2012 1:00 PM
To: Meyer, Maurice
Cc: users_at_subversion.apache.org
Subject: Re: Subversion password encryption

See: http://wiki.apache.org/subversion/EncryptedPasswordStorage

On Mon, Jun 25, 2012 at 3:30 PM, <Maurice.Meyer_at_wellsfargo.com> wrote:
> Hello,
>
> I just got through reading the "How to report a bug" page but what I have is
> more of an enhancement request.  Not sure if it belongs here but I'll
> writeup either way just in case.
>
> I am fairly new to Subversion but have nearly 20 years experience with
> ClearCase and Perforce strongly rooted in UNIX but in a mixed environment
> for quite some time.  Since I work for a large bank, we have pretty tight
> security requirements which are monitored by external groups.  We use
> Solaris, Redhat and Windows here.  Using the Apache 1.7.4 version of SVN, we
> ran into the obvious issue that SVN will store passwords in clear text.
> We've been working with people at WANDisco to setup Gnome support for the
> password encryption and will have a solution in place shortly.  But, I have
> to say that the Gnome solution is less than desirable.  Issues being:
>
> 1. It requires that users to manage daemon processes which is fragile and
> leads to support queries.
> 2. Users must enter the gnome keyring password making cron job scheduling
> difficult.
> 3. The killall method of stopping gnome processes can knock out processes
> running for another login session.
>
> There is more to talk about in the nuances of how Gmone works but I'll get
> more to the point which is: I'd like to request a simplified encryption
> scheme native to SVN even if it comes with some security caveats.  Something
> that:
>
> 1. Does not involve any external process or at least only one that the
> system manages and not the users.
> 2. Could be exactly what scheme is used for UNIX password encryption into
> the passwd file.
> 3. Could be some system where a file on the SVN server lists trusted
> machines so users from those machines don't have to enter a password.
>
> I am not a security expert but I feel like we're going from zero
> (non-encrypted) to overkill (Gnome) without any intermediate choices.
>
> It seems that this would be a fundamental enough issue that would interest
> lots of other SVN users.  I'm hoping that there is already some effort
> underway on this topic.
>
> Thanks
>
> Maurice Meyer
>
> This message may contain confidential and/or privileged information, and is
> intended for the use of the addressee only. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose, or take any action based on this message or any information
> herein. If you have received this message in error, please advise the sender
> immediately by reply e-mail and delete this message. Thank you for your
> cooperation.
>
>
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-06-25 23:04:43 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.