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

RE: Bikeshed: configuration override order

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 10 Aug 2010 14:54:26 -0400

> On 08/07/2010 12:18 PM, Greg Hudson wrote:
> > My thinking about repository configuration is that the uses cases
> > should be divided into two categories:
> >
> > 1. Stuff that isn't really client configuration at all, like
> > auto-props, should come from the repository instead, and should
> only
> > come from client configuration for compatibility.
> >
> > 2. Stuff that is client configuration should only come from
> client
> > configuration. Client control is not legitimate business for an
> open
> > source product, though it could be the business of a proprietary
> > value-added fork.
> Are you saying that client control isn't legitimate because of some
> fluffy open-source principle that checks that right at the door, or
> because of the practical impossibility due to the fact that the
> client source code is available for modification and recompilation?

The latter. I see no problem having it baked into the client. But, the fact that it is open source makes it easy for someone to get a client that doesn't respect repository settings.... so it isn't practical to list it as a [trustable/secure/enterprise level] feature unless perhaps svn was creating signed binaries and a repo could be set to only work with such a signed binary.

Imagine the feature list:

o Repository/Server enforced client settings assuming a client that supports this feature is used.

I'm not sure that will work. But if you said something like:

o Repository/Server declared client settings enforced at the server is possible without the need for script hooks.
   (It is not possible to enforce client side password storage, blah blah)

I think the later is more practical. I am certainly no open source purist.

> The foremost bit of client configuration that CollabNet's
> Subversion customers are demanding (besides auto-props, which I
> think we all agree on) is a way for the server to set a policy
> which dictates that clients may not use plaintext or other insecure
> password storage mechanisms. I claim it's ridiculous to propose
> that we need a custom fork of Subversion, Subclipse, TortoiseSVN,
> AnkhSVN, etc. -- all just to bang in this feature.

I agree with you. See above.

> What, then, do
> you propose? Do you use server-side configuration to demand, say,
> client certs (which you still can't guarantee are passphrase-
> protected, right?)?

I think my point here is that you can't guarantee anything on the client side.

> Do you rip insecure password storage out of Subversion altogether?

Perhaps, although I'm still not sure that solves the problem. There are several tools like multi-clip board apps and such that will still allow a user from doing stupid stuff.

Also, hasn't the svn team taken the stance that it's a version control system, the best a malicious client can do it commit stuff... no data in the repo can be lost. Granted, that is a fall back.

If we are strictly talking about security here, which we aren't, I think there are also ways to secure access to the repository outside of svn security like VPNs, network security, etc.


Received on 2010-08-10 20:55:07 CEST

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.