> 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.
BOb
Received on 2010-08-10 20:55:07 CEST