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

Re: Alternatives for remote access?

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-08-30 16:59:41 CEST

Justin Erenkrantz wrote:
> On Fri, Aug 30, 2002 at 10:45:21AM +0300, Nuutti Kotivuori wrote:
>> I can realize why ra_local was needed before ra_pipe - and I can
>> explain to myself why ra_dav was started before ra_pipe - but if we
>> compare the usefulness of different methods, I must say that
>> ra_pipe should be the first.
>
> Nope, I'd say ra_pipe is by far the least useful of all potential
> RA methods. Yet, if you restrict your world model to how CVS works,
> you'll be uncomfortable using anything other than ra_pipe.

If we think about the basic user who starts using Subversion for his
own projects. First he'll make a repository - and then he'll access it
with ra_local. Then the next thing he's going to want is to access his
same repository from his other machines, a friends machine and and the
machine at work. That's how I wanted it, that's how everybody I've
seen start using Subversion have wanted it to this date.

It'll be a far cry bigger thing to install Apache2, install
mod_dav_svn, configure apache, generate SSL certificates, set up
authentication, open up port 443 in the firewall - and then maintain
this setup. Actually, in most of the place people want to have their
repositories, they don't even have admin access themselves. Telling
the administrator of the shell "Hey, apt-get install subversion,
thanks!" is something that's going to happen in 5 minutes. Telling the
same administrator "Hey, apt-get install apache2 subversion
mod_dav_svn, and then let me configure it. Oh yeah and open up port
443 from your firewall, too!" is going to get some quite colorful
language as a response.

It's obvious that most corporate repositories are going to use ra_dav
- and so are all the public open source repositories. So that's a
pretty big bunch of people.

But I can almost claim that even more people are having
homedirectories, petty weekend projects, webpages, articles and all
sorts of little stuff lying around in CVS repositories - and those
repositories are in their home directores, not in a system place,
accessible only by them and perhaps a few other guys. And they are not
going to use Apache for their repository serving - no, they are going
to use ra_local and ra_dav, depending on which machine they happen to
be on at the moment.

> IMHO, DAV is going to be the most useful by far. It'll be the only
> RA implementation with ACL support. That is a huge advantage.

In a general sense I agree. With everything DAV is going to be, in the
near future, it's going to be very useful. But it has nothing to do
with the cases where ra_pipe would be useful.

> And, I don't buy that ra_dav + mod_ssl is going to be inherently
> less secure than ra_pipe + SSH. Actually, since SSH access would
> require a local account, I'd posit that ra_pipe + SSH is *less*
> secure than ra_dav + mod_ssl.

I don't buy that either the way you put it. You can try and sell it
with SSH being smaller to audit - but that hasn't stopped security
holes from being found.

But that's besides the point. SSH is one access point, Apache is
another. And I'm saying that _two_ access points is much more insecure
than one. Not to mention that you might have to handle two sets of
authentication as well.

See the drift here? I don't say there's a need for ra_pipe + SSH if
you are not giving shells on the machine - if on the other hand shells
is the only thing everybody has - then every solution that involves
running Apache locally with port-forwarding and such is a hellish
kludge, compared to ra_pipe access.

-- Naked

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 17:06:02 2002

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.