[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: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-30 23:12:40 CEST

> From: John P N Pybus [mailto:john.pybus@zoology.oxford.ac.uk]
> On Friday 30 Aug 2002 7:03 pm, Bill Tutt wrote:
> > > From: Ben Collins-Sussman [mailto:sussman@collab.net]
> > >
> > > "Bill Tutt" <rassilon@lyra.org> writes:
> > >
> > > No amount of engineering or slick install programs are going to
> > > eliminate the fact that we require people to adopt a *new*
> > > infrastructure and/or service. And that's the problem.
> >
> > No it's not. Most people think that using SSH gets around that
> > That's a fallacy. Subversion is a new security threat vector, it
> > to be evaluated/audited on its own anyway. People are complaining
> > Subversion is more obvious in being a new threat vector. Well, wah,
> > wah. Every new piece of software is a new threat vector. Ra_pipe
> > helps folks hide the detail that it's a new threat vector from their
> > security folks. In general, I think that's a very bad thing. All
> > vectors should be seriously and carefully considered.
> I think this is coming from one particular viewpoint, that of offering
> securing a service to a wide community of users. This is
> the
> initial focus of subversion, with its collab.net roots, but VC is not
> like that.

Of course, I was talking mainly about some folks in the thread where my
comments do apply, they certainly don't apply everywhere.
> As an example, in our workgroup here I'm sysadmin. I run apache web
> servers,
> file servers, ftp servers, db servers etc (and it takes a reasonable
> amount
> of effort to keep them all running reliably and securely). This
includes a
> CVS service (which I'd ideally like to be able to change to
subversion) to
> support our development projects. The problem is that once people
> to
> use VC for central projects they like it [0], and start wanting to use
> on
> their workstation for private use: config files, local projects etc.
> Subversion would support this but only until they want to access it
> laptop/home, or give access to a colleague.

[A very good explanation of a computing environment....]

> It's true that ssh is often used to offer CVS version control as a
> service (see sourceforge), but that is due to the limitations of
> and
> only clouds the real distinction between making a local repository
> available
> for remote use by a user of that workstation, and running VC as a
> service.

This is a very good point and points towards the middle of the road
solution as Ben Sussman did earlier. The laptop case/remote case can be
handled with distributed repository support eventually, but this middle
of the road does require the middle of the road solution. Feel free to
help implement it. :)

> > Oh, and lest I forget to mention, that doing automated testing of
> > ra_pipe middle road isn't too much fun because it does rely on ssh?
> > Whee...
> What nonsense. Ra_pipe is, as its name suggests, a protocol to work
> a
> pair of pipes. That this IO _can_ be passed over ssh to implement
> access doesn't mean that it has to. Ra_pipe shouldn't need to know
> its
> pipes connect to, that's rather its point. This sounds a little like
> to
> me.

I don't think so, but then again I wrote it. :) I think ra_pipe should
know that its communication channels are secure, if they aren't then
we're doing everyone a huge disservice by creating insecure distributed
software. I, like some other folks mentioned earlier want to support
ACLs on non-ra_dav RA access mechanisms, and the only way you can do
that is to require that ra_pipe, or ra_* fit into the authentication
system somehow. Not to mention if your tests don't use ssh, then you're
not correctly testing your system. Users will use ssh, and if you don't
use ssh in your tests then the tests are next to useless. End to end
integration tests are necessary.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 23:13:09 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.