This is a "me-too" message. I strongly, deeply request you give priority to the
proposal for a new auth mechanism for svnserve. It would help us immensely if
it had a mechanism so passwords don't have to be in the clear; perhaps they
could be stored like Apache passwords (encrypted with htpasswd).
I'll give a bit of background to explain why we care. Version control in my
organization is managed by individual users. Users keep repositories in their
Unix home directories. In other words, there is nothing like a SourceForge
server inside my org where all projects are kept. People collaborate with
others in their own repositories, so obviously groups need write access to that
Https access works, but requires an admin to get involved every time a user
creates a new repository or wants to change the list of authorized users for a
repository. (This is much like how things work now for us with CVS: we use
open-source software that is a CVS authentication daemon, it does set-uid and
such, works fine, but requires admin care-and-feeding.)
We chose to use svnserve because it holds the promise that users can administer
their own repositories, minimizing admin involvement. We set up a Unix group
"svn" and run the svnserve process with a user ID in that group. A user who
wants to share a SVN repository must also be in the svn group. Folders and
files in the SVN repository must have group svn, with group write permission.
And the net result is that it works (although we wish we could have logging --
I wrote to the list separately).
The downside is that the svnserve password file in every repository's "conf"
folder must be readable by the svnserve process. It could be owned by the svn
user id and mode 444, but that would prevent users from changing things.
Because all of our unix users work in a big, shared-via-NFS world, the net
result is that every respository owner can read any other shared repository.
(Yes, we use FSFS as the repository format.) This is not currently a fatal
problem but it sure isn't nirvana.
I'm sure not an authentication or encryption expert, but I can try to work on
this problem if someone can get me started. (No, I'm not a student, this is
not a summer of code for me. :-/)
Thanks for listening. I very much welcome your feedback if I missed something
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jul 28 18:00:25 2005