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.
