> 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*
security
> > > infrastructure and/or service. And that's the problem.
> >
> > No it's not. Most people think that using SSH gets around that
problem.
> > That's a fallacy. Subversion is a new security threat vector, it
needs
> > to be evaluated/audited on its own anyway. People are complaining
that
> > Subversion is more obvious in being a new threat vector. Well, wah,
wah,
> > wah. Every new piece of software is a new threat vector. Ra_pipe
just
> > 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
threat
> > vectors should be seriously and carefully considered.
>
> I think this is coming from one particular viewpoint, that of offering
and
> securing a service to a wide community of users. This is
understandably
> the
> initial focus of subversion, with its collab.net roots, but VC is not
all
> 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
start
> to
> use VC for central projects they like it [0], and start wanting to use
it
> on
> their workstation for private use: config files, local projects etc.
> Subversion would support this but only until they want to access it
from
> 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
network
> service (see sourceforge), but that is due to the limitations of
pserver,
> 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
network
> 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
this
> > 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
over
> a
> pair of pipes. That this IO _can_ be passed over ssh to implement
remote
> access doesn't mean that it has to. Ra_pipe shouldn't need to know
what
> its
> pipes connect to, that's rather its point. This sounds a little like
FUD
> 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.
Bill
---------------------------------------------------------------------
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