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

RE: svnserve password store in clear text

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-06-07 15:39:38 CEST

"Ng, Wey Han" <weyhan.ng@atosorigin.com> wrote on 06/07/2004 07:17:18 AM:

> > -----Original Message-----
> > From: kfogel@collab.net [mailto:kfogel@collab.net]
> > Sent: Friday, June 04, 2004 11:48 PM
> >
> > Apache doesn't imply shell access.
> >
> > ??
>
> You are right. Thanks for being the first to correct me on this
fundamental
> oversight. For some reason, I have always associated Apache access with
> http+ssl.
>
> Since I have read your post, I have gone back and read more carefully
the
> apache section of the book. With the instruction on the book, I have
tried
> the whole day to configure apache to work with subversion but I can only
get
> to brows with a web client and not a svn client. As compare to svnserve,
I
> just spend half a day to get it all up. I am starting to feel that
Apache
> setup for Subversion is beyond me.
>

Why don't you post some more information about what you are doing and the
problems?

What version of Apache? Ideally, you should use 2.0.49, but it has to be
at least 2.0.48 (I believe). If the browsing works from a web browser,
that would imply you are setup correct. What Subversion commands are you
running that fail?

> Not around here. I can't get ssh installed on any of the serve except
the
> one I have control over.

That is why Apache should be easier, you do not need ssh or anything
special on the client. SSL is built into your Apache server and the
Subversion clients. Of course you only need SSL if you want to encrypt
the traffic on your LAN anyway, not sure you have ever said you need that
kind of security. By the way, you do realize that when using SSL, the URL
is https:// not http+ssl://?

> Also, so far I have only seen two types of authentication system used
with
> Apache. That is the basic username password scheme and also ssl certs.
> Please define "whatever user and password system". I am more then
willing to
> explore other options if it fits into the limitation I am facing and not
> very involved for administration work beyond the initial setup.

I did not have anything specific in mind, I just meant that there are a
lot of options available for Apache. I was thinking LDAP, but you have
already said that you are not allowed to do that. I think a while back
someone posted a link to a fairly nice CGI based system for managing users
and password using the basic Apache system. This would just be one less
piece to write yourself.

> Some form of web interface for user to change their password along with
> initial password for them to login to change their password. Hashing
will be
> done in the cgi script. My aim is to be as maintenance free as possible
> because I am not an administrator and my performance is not evaluated
based
> on doing system administration work. But I am willing to spend some time
> initially to set it up so that it is "maintenance free (tm)".

I guess I see what you are saying here, but also I think it clear that
this web based interface is something you would have to write yourself and
would not make sense as part of svnserve since it's point is to not have
an HTTP server in the first place. If you web based interface updated the
svnserve conf file and hashed the passwords, I guess it would be nice if
svnserve could use those hashed passwords. But there is a tough problem
to solve inherent in this:

1) svnserve cannot require an HTTP interface (or any other UI) to manage
its config files. That defeats the whole point of svnserve.

2) Without an HTTP interface, there is little value in a hashed password
solution

That is why it would be better to work out the Apache option, and invest
your effort into writing an HTTP interface for managing your Apache users
and passwords.

Good luck. I think if you post some more info, we can get your Apache
working.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 15:40:27 2004

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

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