[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 20:03:38 CEST

> From: Ben Collins-Sussman [mailto:sussman@collab.net]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > The setup burden is currently high, so feel free to help us engineer
the
> > lowering of that barrier.
>
> 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.

> Most of the world has an existing security infrastructure. It's
> called ssh. We could have decided to just "fit into it" magically
> like CVS, but we didn't, and it's no surprise to me that people don't
> like this. And you shouldn't be surprised either. It has nothing to
> do with whether one method is superior or not; it's a matter of losing
> people before they ever come in the door, because of all the myths
> surrounding the idea of "setting up apache". It's human nature. You
> can't change it. A slick install program isn't going to dispell the
> initial repulsion either. It does no good to say, "tell your security
> people to stop being dorks."
>

I don't want them to do that, that's not productive. What I'm saying is
that the security people need to be educated about Subversion anyway,
not having ra_pipe just helps prod folks in that direction.

> Apache is the "high road", and I'm extremely glad we have it -- and
> ra_local is the low-road for people who don't care about networking.
> But it's ridiculous that we don't have a middle-road. It's ridiculous
> that we demand *everyone* take the high-road, and that we poo-poo them
> for even wanting a middle-road. We want to win over the CVS masses,
> but this attitude absolutely shoots us in the foot.
>

No, it's not ridiculous at all. It's just standard project management
priority management. The middle-road hasn't been a priority because we
want the features of the high road, and the low road for
administrative/testing/convenience purposes. If folks want to help out
with developing the middle road that's perfectly fine, and I welcome
that. However, be prepared for the possible ensuing bitrot if it doesn't
get accompanied by lots of fun automated testing because it is the
middle-road.

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...

> If ra_pipe were out there, we could lure in hundreds of users, and
> then gradually convince them to upgrade to apache and ra_dav. It's
> the best marketing tool there is. I'm thrilled that people are
> working on it.

The best marketing tool is word of mouth praising Subversion for it's
reliability, and lack of suckage vs. CVS. The best way to ensure follow
through on the marketing tool is by reducing the setup barrier. If we
don't have enough positive features to overcome any of the issues
related to not having ra_pipe, then in my view we've failed to add
enough features to make Subversion compelling enough to consider
overcoming whatever issues there are at not having a ra_pipe like model.

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 20:04:10 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.