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..
>
> 1. Under "So, the order in which specific configuration options will be
> honored where found is:", you say that ~/.subversion/ settings would
> be overriden by /etc/subversion settings. That's not how the code
> works today --- i.e., not a compatible change. Typo?
I intended that list to be from highest priority to lowest, just
clarified that. Also added command-line options to the list at the
number 2 spot.
> 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:
>svn up
svn: warning: W720005: Can't open file
'C:\Users\pburba\AppData\Roaming\Subversion\servers': Access is
denied.
Updating '.':
A A\D\H\zeta
Updated to revision 9.
Maybe something like:
>svn up
svn: warning: Unable to cache repository dictated configuration
svn: warning: W720005: Can't open file
'C:\Users\pburba\AppData\Roaming\Subversion\0cf6fea1-e7ef-864b-8ea2-d6d678b87e78\config':
Access is denied.
Updating '.':
A A\D\H\zeta
Updated to revision 9.
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?
> 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?
[[[
Reworking the client-side local configuration to support similar
hierarchies of configuration. Today, the local configuration is
largely universal in terms of remote scope -- changes to the
configuration apply to all working copies of all repositories on all
servers. (Some exceptions exist in the 'servers' file, but those are
largely disinteresting for our purpose.) If the client had access to
hierarchical configuration, users could configure such things as "in
all working copies of ${ASF_REPOS_UUID}:/subversion, do not store
pristines".
Configuration options other than global-ignores, auto-props, and
store-plaintext-passwords.
]]]
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. 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 19:31:16 CET