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

Re: [RFC] Server Dictated Configuration

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 4 Jan 2012 21:02:40 +0200

Paul Burba wrote on Wed, Jan 04, 2012 at 13:30:41 -0500:
> On Tue, Jan 3, 2012 at 6:16 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > On Tue, Jan 3, 2012, at 17:58, Paul Burba wrote:
> >> Mike Pilato and I have been kicking around some ideas on server
> >> dictated configuration recently and have put our thoughts into a wiki
> >> (full disclosure: this wiki was initially based on Hyrum's thoughts on
> >> the subject in https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config)
> >> :
> >>
> >> http://wiki.apache.org/subversion/ServerDictatedConfiguration
> >>
> >> We're at a point where it's time to solicit some wider feedback, so
> >> please have a look at the wiki and follow-up here with any concerns,
> >> thoughts, suggestions, etc..
> >
> > 2. How would failure to create ~/.subversion/repos/${UUID}/foo be
> >   considered?  Fatal error?  Warning-but-continue?
> I'd say the latter, which is what we do now if Subversion cannot
> create the standard run-time config:

+1, for reasons similar to yours.

> My reasoning for this is that we already accept that fact that a
> malicious user can hack up a custom client to ignore the server
> dictated config. We still expect the repository administrator to
> enforce (where possible) their desired configuration via hook scripts.
> All we are trying to do here is make it possible for well-behaved
> clients to *easily* do the right thing.
> > 3. Re password storage: does it make sense to allow the server to push a
> >   "may store plaintext passwords" setting to the client?
> I'm with you to the extent that that doesn't make much sense...
> > That is a
> >   security risk, for example, in environments where the password is not
> >   transmitted on the wire.
> ...but I don't follow how exactly this is a security risk. Could you elaborate?

Sure: I think it's a greater security risk for the server to cause the
client to record on disk a password that the server admin doesn't know,
than the same with a password the server admin knows.

> >   The generic case here is "Allow option <X> to be pushed only to some
> >   of its possible values".
> >
> > 4. In "Related issues", add the title or description of each
> >   issue alongside each number? (Thanks.)
> Done.


> > 5. wrt the '${ASF_REPOS_UUID}:/subversion' use-case, how forward-
> >   compatible is the proposed design to extensions such as that one?
> >   (Not saying that specific extension needs to be possible, but we'll
> >   probably want to extend this feature in various ways in 1.9 and we
> >   don't want it to be as hard as FSFS to extend.)
> By the "'${ASF_REPOS_UUID}:/subversion' use-case" you mean deferred goal #4?
> [[[
> hierarchical configuration, users could configure such things as "in
> all working copies of ${ASF_REPOS_UUID}:/subversion, do not store
> pristines".
> ]]]


> IIUC you want to know how easily the proposed server dictated config
> client-side storage model, i.e. a UUID-keyed subdir for every
> repository supplied configuration, would work with an extended
> client-side configuration model.

Yes. I'm assuming that once we release this feature in 1.8, we will
want to extend it in 1.9. I don't know yet _how_ we'll want to extend
it (deferred goal #4 is but one route we might go down), but I'm asking
how amenable to extensibility is the new format. (Concrete example:
what happens when a 1.9 client writes a ~/.s/repos/ entry, and a 1.8
client then tries to read it?)

> What is proposed for server dictated
> config is obviously not a perfect fit for client side config, e.g. do
> we still have a global ${HOME}/.subversion/config file, and if so, how
> does a UUID-keyed local config override it...but I don't see any
> deal-breakers here for the current proposal.


> Paul


Received on 2012-01-04 20:04:08 CET

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