> 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
