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:
It's also unreliable, since *any* aritrary client can and will store
the plain-text password for HTTP or HTTPS access *unless* you can
control the client setups enough to block the feature.
If you need to provide off-site Subversion access for clients you
don't have control over, It's a losing battle: go directly to svn+ssh,
which relies on SSH keys. Fools can still keep the SSH keys
unencrypted, but it separates access from other password based
authentication and helps prevent the use of merged authentication
technologies, such as Windows or Linux login passwords that should be
secure, wind up stored insecurely.
> 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:
Some of the developers are working on this for version 1.8. That still
won't fix all the 1.7, 1.6, or older clients in th field, but it's a
start.
> 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.
SSL keys or SH keys for svn+ssh.
> I am not a security expert but I feel like we're going from zero
> (non-encrypted) to overkill (Gnome) without any intermediate choices.
See above.
> 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.
Historically, it's been treated much like passphrase free SSH keys.
It's been considered the user's problem that their client machine is
not secure. This, of course, breaks down in microseconds in any
environment where there's NFS version 3 or backup tapes of user's home
directories are commonplace.
Received on 2012-06-27 05:46:02 CEST