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.
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.
We don't run locked down systems for workstations. We have a wide range of
platforms and developers have root on their own box. But (a fairly minimal
IMHO) policy is not to run network services that aren't being actively
maintained by someone. If everyone runs different versions of httpd, ftpd,
etc which they don't necessarily have the time, skills, or responsibility to
maintain, then the exposure is rather too high.
Ssh is a godsend in such an environment. We can make sure that ssh is up to
date on everyone's machine when security issues come up. People don't run
ftpd, they can use sftp just as easily. sftp doesn't add any extra security
risk in this environment [1], and neither would ra_pipe. Running an apache
daemon on everyones workstations for infrequently used remote access would be
a waste of resources even if it were well secured, and once you consider
people having to start/stop a daemon and setup a suitable secure tunnel, it
all starts to look like a support nightmare.
To switch to subversion would probably require that all VC is done on a
centrally run service which is rather a shame, people like the freedom to do
things locally, or that we have svn centrally and recommend CVS on users
workstations (another training, and support nightmare). I may be wrong in
thinking that this sort of hiding small scale access to CVS behind ssh is so
common, but like sftp it certainly has its place.
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.
> 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.
Yours,
John Pybus
[0] This is a good thing :-)
[1] If all the people accessing the system already have shell accounts, sftp
is only a convenience -- it doesn't give you capabilities 'cat' doesn't.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 22:44:14 2002