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...@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.
>
Thanks.
> > 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".
> ]]]
>
Yes.
> 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.
>
OK.
> Paul
Thanks,
Daniel
