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

Re: Medium-term roadmap: 1.3, 1.4, 1.5.

From: Joseph Galbraith <galb_at_vandyke.com>
Date: 2005-04-25 17:27:14 CEST

Ben Collins-Sussman wrote:
> On Apr 25, 2005, at 8:19 AM, Andrew Thompson wrote:
>> Faller, Gyula wrote:
>>> - the third most important is ACLs. Yes, I know, if we would use
>>> Apache instead of svnserve, we got some degree of this, but why we
>>> should use Apache for a subversion feature?
>> I have been trying to figure out why a single repository is considered
>> *good*, yet we can't limit access to portions of it without a third
>> party application.
> Yes, the developers would like to see ACLs within the repository itself
> someday. But I'm not sure where this attitude of turning noses at "3rd
> party application" comes from.
> For Subversion 1.0, our decision was that access-control happened at the
> server level. As I see it, there aren't any 3rd-party applications
> doing authorization:
> * both svnserve and mod_dav_svn have the ability to launch pre-commit
> hooks to enforce authorization. Neither of those are 3rd-party tools;
> the hook functionality is part of the core svn codebase.
> * mod_authz_svn is a module to do authorization all by itself. It's
> not a 3rd party tool, and it's also part of the core svn codebase.
> Apache is no more a "3rd party application" than any other depenency,
> like neon for example.

At least for me, it is a matter of having to install and
configure a 'third' piece of software (and not a trivial
one either!)

And at my company (a windows shop) the requirement to use
apache to deny certain users read access to certain files in the
repository (functionality we have with SourceSafe) is a
hard sell (and rightfully so.)

I don't think it is hard to argue that svnserve has a _lot_
smaller attack surface than apache. Apache definitely increases
the initial install investment (more IT time to get it up
and running) and the maintance investment (more complex
configuration to keep up to date; more components that
need updating.)

On the other hand, we already run SSH. Adding svnserve seems
like a lot more reasonable size chunk to bite off. Or even
running svnserve directly (if it had SSL support.)



PS. I think the decision to use apache for security in 1.0 was a very
reasonable decision... I just wouldn't want to see it become permenant.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 25 17:26:21 2005

This is an archived mail posted to the Subversion Dev mailing list.