RE: Bikeshed: configuration override order
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: woensdag 11 augustus 2010 15:42 > To: Branko Čibej; dev@subversion.apache.org > Subject: RE: Bikeshed: configuration override order > > > On 11.08.2010 11:05, Bolstridge, Andrew wrote: > > > The second aspect: client-stored passwords, this isn't so much > > about storing them on the client but about having different ones. > > Enterprises want single-signon, ie, a single password, centrally > > held, that is used for all apps. They don't really care about > > storing it locally so much as caring when Mildred calls the > > helpdesk to say her password doesn’t work only to find she's > > changed her main login but her svn password is the old, different > > one. I don't think there's much to do here, except to get LDAP > > working. Fortunately, VisualSVN allows integrated authentication > > with Active Directory, and most enterprises still use Windows. > > > > > > > What has that got to do with anything? You stock plain-vanilla > > Subversion server can integrate with Active Directory just fine, if > > you're serving via Apache. You don't need VisualSVN for that. So a > > password update will change the SVN password, said user will > > receive a > > password prompt from the Subversion client *once*, and SVN will > > presumably store that password securely (at least, it will on > > Windows). > > > > -- Brane > > I've never used LDAP but doesn't windows handle passing credentials tokens > in the background... you should never be prompted for credentials is you are > using LDAP other than when you sign into your windows/domain account. LDAP is a directory protocol; it allows to verify and get information about tokens. SSPI (as implemented by mod_auth_sspi, neon and serf) handles the logon without asking for credentials. If you want to check group membership and other details you can combine these two systems. (That is how I configured it at TCG). Bert
RE: Bikeshed: configuration override order
> On 11.08.2010 11:05, Bolstridge, Andrew wrote: > > The second aspect: client-stored passwords, this isn't so much > about storing them on the client but about having different ones. > Enterprises want single-signon, ie, a single password, centrally > held, that is used for all apps. They don't really care about > storing it locally so much as caring when Mildred calls the > helpdesk to say her password doesn’t work only to find she's > changed her main login but her svn password is the old, different > one. I don't think there's much to do here, except to get LDAP > working. Fortunately, VisualSVN allows integrated authentication > with Active Directory, and most enterprises still use Windows. > > > > What has that got to do with anything? You stock plain-vanilla > Subversion server can integrate with Active Directory just fine, if > you're serving via Apache. You don't need VisualSVN for that. So a > password update will change the SVN password, said user will > receive a > password prompt from the Subversion client *once*, and SVN will > presumably store that password securely (at least, it will on > Windows). > > -- Brane I've never used LDAP but doesn't windows handle passing credentials tokens in the background... you should never be prompted for credentials is you are using LDAP other than when you sign into your windows/domain account. BOb
Re: Bikeshed: configuration override order
On Wed, Aug 11, 2010 at 6:05 AM, Bolstridge, Andrew wrote: >> -Original Message- >> From: Branko Čibej [mailto:br...@xbc.nu] >> Sent: Wednesday, August 11, 2010 10:37 AM >> To: dev@subversion.apache.org >> Subject: Re: Bikeshed: configuration override order >> >> On 11.08.2010 11:05, Bolstridge, Andrew wrote: >> > The second aspect: client-stored passwords, this isn't so much about >> storing them on the client but about having different ones. Enterprises want >> single-signon, ie, a single password, centrally held, that is used for all >> apps. They don't really care about storing it locally so much as caring when >> Mildred calls the helpdesk to say her password doesn’t work only to find >> she's changed her main login but her svn password is the old, different one. >> I don't think there's much to do here, except to get LDAP working. >> Fortunately, VisualSVN allows integrated authentication with Active >> Directory, and most enterprises still use Windows. >> > >> >> What has that got to do with anything? You stock plain-vanilla >> Subversion server can integrate with Active Directory just fine, if >> you're serving via Apache. You don't need VisualSVN for that. So a >> password update will change the SVN password, said user will receive a >> password prompt from the Subversion client *once*, and SVN will >> presumably store that password securely (at least, it will on Windows). >> > > I should have been a little clearer - VisualSVN Server (the enterprise > version) has the ability to log you on automatically without asking for a > password at all. > I know Apache can do it too - VisualSVN Server (non-enterprise version) does > that, but requires the client to supply a password as per normal. It doesn't > need a separate password auth list as it uses the LDAP support in Apache > (note that VisualSVNServer is apache under the covers). FWIW, the LDAP module in Apache 2.4 will have better integration with LDAP authorization, not just authentication. It should theoretically* be possible to call back from mod_dav_svn to mod_ldap to do authorization, instead of relying upon mod_authz_svn. It probably won't be trivial to write the patch to do the integration, but still an interesting possibility. -Hyrum * - I have not personally investigated this at all, it's just based on a recent conversation with some httpd devs.
RE: Bikeshed: configuration override order
> -Original Message- > From: Branko Čibej [mailto:br...@xbc.nu] > Sent: Wednesday, August 11, 2010 10:37 AM > To: dev@subversion.apache.org > Subject: Re: Bikeshed: configuration override order > > On 11.08.2010 11:05, Bolstridge, Andrew wrote: > > The second aspect: client-stored passwords, this isn't so much about > storing them on the client but about having different ones. Enterprises want > single-signon, ie, a single password, centrally held, that is used for all > apps. They don't really care about storing it locally so much as caring when > Mildred calls the helpdesk to say her password doesn’t work only to find > she's changed her main login but her svn password is the old, different one. > I don't think there's much to do here, except to get LDAP working. > Fortunately, VisualSVN allows integrated authentication with Active > Directory, and most enterprises still use Windows. > > > > What has that got to do with anything? You stock plain-vanilla > Subversion server can integrate with Active Directory just fine, if > you're serving via Apache. You don't need VisualSVN for that. So a > password update will change the SVN password, said user will receive a > password prompt from the Subversion client *once*, and SVN will > presumably store that password securely (at least, it will on Windows). > I should have been a little clearer - VisualSVN Server (the enterprise version) has the ability to log you on automatically without asking for a password at all. I know Apache can do it too - VisualSVN Server (non-enterprise version) does that, but requires the client to supply a password as per normal. It doesn't need a separate password auth list as it uses the LDAP support in Apache (note that VisualSVNServer is apache under the covers). That doesn't mean that svn (without Apache) doesn’t need LDAP support itself, Svnserve should support that natively as we're talking about the svn tools, not just svn-inside-apache. Andy
Re: Bikeshed: configuration override order
On Tue, Aug 10, 2010 at 11:12:25PM +0200, Branko Čibej wrote: > The issue isn't storing passwords, but storing them insecurely, i.e., in > plaintext on disk. Which is what Subversion does by default unless it Not "by default" anymore. As of 1.6.0, the default is to *ask* the user whether storing passwords in plaintext is OK. That is very different to just storing passwords in plaintext by default. > I think it's perfectly valid for a shop to force its users to store > passwords securely, but I wonder if server-side configuration is the way > to do it -- I'd rather expect them to provide the right sort of client > for the right sort of system. I'm wondering about the same question. See my earlier response upthread: http://svn.haxx.se/dev/archive-2010-08/0180.shtml > On 10.08.2010 20:57, Greg Hudson wrote: > > (*) Actually, on consideration, there was some flap about the "okay to > > print" flag in PDF documents, or something related to that. I can't > > remember how it turned out. There are patches for xpdf that disable all of its DRM features. That's how it turned out. Stefan
Re: Bikeshed: configuration override order
On 11.08.2010 11:05, Bolstridge, Andrew wrote: > The second aspect: client-stored passwords, this isn't so much about storing > them on the client but about having different ones. Enterprises want > single-signon, ie, a single password, centrally held, that is used for all > apps. They don't really care about storing it locally so much as caring when > Mildred calls the helpdesk to say her password doesn’t work only to find > she's changed her main login but her svn password is the old, different one. > I don't think there's much to do here, except to get LDAP working. > Fortunately, VisualSVN allows integrated authentication with Active > Directory, and most enterprises still use Windows. > What has that got to do with anything? You stock plain-vanilla Subversion server can integrate with Active Directory just fine, if you're serving via Apache. You don't need VisualSVN for that. So a password update will change the SVN password, said user will receive a password prompt from the Subversion client *once*, and SVN will presumably store that password securely (at least, it will on Windows). -- Brane
RE: Bikeshed: configuration override order
> -Original Message- > From: Julian Foad [mailto:julian.f...@wandisco.com] > Sent: Tuesday, August 10, 2010 6:25 PM > To: C. Michael Pilato > Cc: Bolstridge, Andrew; Subversion Development > Subject: Re: Bikeshed: configuration override order > [snip] > > Oh? All I know about Andrew's particular requirements related to this > query is what's quoted above - "If I ... accidentally leave the banned > buildlog.htm file in ..." - which sounded vaguely like a requirement for > a path-based rule. Maybe I missed something. > Drats! My hopes that an invalid commit might go faster because I'd made a mistake in understanding the hooks was cruelly dashed. In a way it is a path-based rule - I want certain file extensions (eg. *.obj) , certain directories (eg Debug) and certain explicit files (eg buildlog.htm) to be barred from the repo. I used buildlog.htm as an example because it's easy to flip through the list to commit and mark the obvious ones off, but not so easy to keep all htm files, except that one. Still, the client global-ignores is great, I just want to store it on the server. The second aspect: client-stored passwords, this isn't so much about storing them on the client but about having different ones. Enterprises want single-signon, ie, a single password, centrally held, that is used for all apps. They don't really care about storing it locally so much as caring when Mildred calls the helpdesk to say her password doesn’t work only to find she's changed her main login but her svn password is the old, different one. I don't think there's much to do here, except to get LDAP working. Fortunately, VisualSVN allows integrated authentication with Active Directory, and most enterprises still use Windows. It's still all about centrally-held configuration and not having to discover what a client may or may not happen to be using.
Re: Bikeshed: configuration override order
On Tue, 2010-08-10, C. Michael Pilato wrote: > On 08/10/2010 01:25 PM, Julian Foad wrote: > > Oh? All I know about Andrew's particular requirements related to this > > query is what's quoted above - "If I ... accidentally leave the banned > > buildlog.htm file in ..." - which sounded vaguely like a requirement for > > a path-based rule. Maybe I missed something. > > I don't think you missed the requirement. You merely offered a > non-solution. :-) Andrew said (essentially), "I need path-based rule > enforcement, but the one you offer -- the pre-commit hook -- has this nasty > side effect of only kicking in after the entire commit payload is on the > server." You replied, "No - there are two different hooks, for precisely > this reason." But Andrew can't benefit from that other hook, because it > can't do path-based rule enforcement. D'oh. I was stupid and didn't check. I wrongly thought - or guessed - the start-commit hook had the list of file paths available, just without the files' new text, but in fact it gets only # [1] REPOS-PATH (the path to this repository) # [2] USER (the authenticated user attempting to commit) # [3] CAPABILITIES (a colon-separated list of capabilities reported # by the client; see note below) Thanks. - Julian
Re: Bikeshed: configuration override order
C. Michael Pilato wrote on Tue, Aug 10, 2010 at 14:24:30 -0400:
> 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.
^^
Such as post-it notes?
[[[
Index: subversion/mod_dav_svn/mod_dav_svn.c
===
--- subversion/mod_dav_svn/mod_dav_svn.c(revision 983930)
+++ subversion/mod_dav_svn/mod_dav_svn.c(working copy)
@@ -837,6 +837,12 @@
"enables server advertising of support for version 2 of "
"Subversion's HTTP protocol (default values is On)."),
+ /* per directory/location */
+ AP_INIT_FLAG("SVNBanPostItNotes", SVNBanPostItNotes_cmd, NULL,
+ ACCESS_CONF|RSRC_CONF,
+ "enable server refusing of checkouts to clients that use "
+ "post-it notes (this is a security risk)"),
+
{ NULL }
};
]]]
Re: Bikeshed: configuration override order
On 10.08.2010 20:57, Greg Hudson wrote: > On Tue, 2010-08-10 at 14:24 -0400, C. Michael Pilato wrote: > >> 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 don't expect anyone to consider my opinion blocking, but I think this > is a questionable area for any kind of software to delve into. I've > only seen this kind of client control in one other context (a branded > Jabber client), and never in an open source project. (*) > > Lots and lots of clients are able to remember passwords: web browsers, > email clients, IM clients. Lots of central IT organizations (MIT's > included) don't like this feature and recommend that users not use it. > Lots of users do it anyway. I don't know of a single piece of > widely-used client software which allows the server to turn off password > memory. > The issue isn't storing passwords, but storing them insecurely, i.e., in plaintext on disk. Which is what Subversion does by default unless it specificaly supports secure password storage on the client system -- IIRC the supported systems are Windows (with CryptoAPI), MacOS (with Keychain) and Linux (with Kwallet or gnome-keychain, which I suppose aren't really limited to Linux). I think it's perfectly valid for a shop to force its users to store passwords securely, but I wonder if server-side configuration is the way to do it -- I'd rather expect them to provide the right sort of client for the right sort of system. > (*) Actually, on consideration, there was some flap about the "okay to > print" flag in PDF documents, or something related to that. I can't > remember how it turned out. >
Re: Bikeshed: configuration override order
On Tue, 2010-08-10 at 14:24 -0400, C. Michael Pilato wrote: > 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 don't expect anyone to consider my opinion blocking, but I think this is a questionable area for any kind of software to delve into. I've only seen this kind of client control in one other context (a branded Jabber client), and never in an open source project. (*) Lots and lots of clients are able to remember passwords: web browsers, email clients, IM clients. Lots of central IT organizations (MIT's included) don't like this feature and recommend that users not use it. Lots of users do it anyway. I don't know of a single piece of widely-used client software which allows the server to turn off password memory. (*) Actually, on consideration, there was some flap about the "okay to print" flag in PDF documents, or something related to that. I can't remember how it turned out.
RE: Bikeshed: configuration override order
> 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
Re: Bikeshed: configuration override order
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 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. 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?)? Do you rip insecure password storage out of Subversion altogether? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Bikeshed: configuration override order
On Tue, Aug 10, 2010 at 06:25:15PM +0100, Julian Foad wrote: > All I know about Andrew's particular requirements related to this > query is what's quoted above - "If I ... accidentally leave the banned > buildlog.htm file in ..." - which sounded vaguely like a requirement for > a path-based rule. Maybe I missed something. The start-commit hook doesn't know what paths the client will touch during the commit. It only knows which user is making the commit, and the capabilities advertised by the client (like "I can do merge tracking"). It can be used to temporarily make an entire repository read-only, by rejecting any commit. But it can't make decisions based on the content of a commit. Stefan
Re: Bikeshed: configuration override order
On 08/10/2010 01:25 PM, Julian Foad wrote: > Oh? All I know about Andrew's particular requirements related to this > query is what's quoted above - "If I ... accidentally leave the banned > buildlog.htm file in ..." - which sounded vaguely like a requirement for > a path-based rule. Maybe I missed something. I don't think you missed the requirement. You merely offered a non-solution. :-) Andrew said (essentially), "I need path-based rule enforcement, but the one you offer -- the pre-commit hook -- has this nasty side effect of only kicking in after the entire commit payload is on the server." You replied, "No - there are two different hooks, for precisely this reason." But Andrew can't benefit from that other hook, because it can't do path-based rule enforcement. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
RE: Bikeshed: configuration override order
> > Summary... > > > > There are two issues here... > > > > 1. The repo admin wants to enforce what is commited to their > repo. > This > > exists with scripts but common request can be made inherient repo > settings > > (probably need to be path based). > > > > The issue with pre-commit hooks is that they are run after all data > is > transferred - so if I commit loads of data, and accidentally leave > the > banned buildlog.htm file in... I'll find out about it after half an > hour's commit.. and have to repeat the process. It's not that major > an > issue but repo-set config would fix it. Auto-props is a more tricky > problem that would just be nicely solved by telling the clients > what > settings to use. > > > > 2. The admins want to simplify config for clients committing to > repos > that > > have various enforcements made (see item 1) without needing to > deal > with > > distirbuting client config files or what have you. > > This is the biggie - one remote worker decided he didn't have to > read > all the email I sent him on how to set up svn, and ended up > committing 2 > Gb of crud to my lovely repository. We have a pre-commit hook for > all > file extensions now. > > > Anyway, that's my thoughts on the subject. Repo-driven config, even > if > its just an easy way to download a new set to the client instead of > the > email 'use this file, or use this registry script' is a huge step > forward. > > Andy This is why I am trying to say it needs to be a two layer configuration. The settings on the server are enforced before anything is committed to the repo. The settings are also sent to the client (in some way) yes, to avoid that 5 minute or whatever wait. However I think shooting for client enforcement and trusting the client isn't something svn should rely on. It is similar to writing a web app where you have client side validation/sanitation... but you still ALWAYS duplicate that validation/sanitation on the server... because you really have no way to trust that someone isn't posting bad data to your server/services using a client that isn't the one you provided. I think the same approach has to be taken here. The server side config is provided to the client as a convenience but it is always enforced on the server (without the need to write scripts) because you can't always trust the client to be using or respecting "forced" repository configuration. BOb
Re: Bikeshed: configuration override order
On Tue, 2010-08-10, C. Michael Pilato wrote: > On 08/10/2010 01:10 PM, C. Michael Pilato wrote: > > On 08/10/2010 12:15 PM, Julian Foad wrote: > >> On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote: > Summary... > > There are two issues here... > > 1. The repo admin wants to enforce what is commited to their repo. > >>> This > exists with scripts but common request can be made inherient repo > >>> settings > (probably need to be path based). > > >>> > >>> The issue with pre-commit hooks is that they are run after all data is > >>> transferred - so if I commit loads of data, and accidentally leave the > >>> banned buildlog.htm file in... I'll find out about it after half an > >>> hour's commit.. and have to repeat the process. > >> > >> No - there are two different hooks, for precisely this reason. > >> pre-commit runs before all the file contents are transferred, and > >> start-commit after all the file contents are transferred. > > > > Er... no. > > > > 'start-commit' runs before any files are transferred. It can't be used to > > fail a commit based on any information that comes from the commit's tree > > delta content payload. > > > > 'pre-commit' runs just before the commit transaction is promoted into a > > revision, and can be used to block commits based on the content payload. > > But only after the whole payload is transmitted to the server. > > In other words, I think you were essentially correct about the two-hook > system, Julian -- you just had the hooks switched. But regardless, the Thanks for correcting me. > two-hook system still fails Andrew's particular enforcement requirements > (which are quite common). Oh? All I know about Andrew's particular requirements related to this query is what's quoted above - "If I ... accidentally leave the banned buildlog.htm file in ..." - which sounded vaguely like a requirement for a path-based rule. Maybe I missed something. - Julian
Re: Bikeshed: configuration override order
On 08/10/2010 01:10 PM, C. Michael Pilato wrote: > On 08/10/2010 12:15 PM, Julian Foad wrote: >> On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote: Summary... There are two issues here... 1. The repo admin wants to enforce what is commited to their repo. >>> This exists with scripts but common request can be made inherient repo >>> settings (probably need to be path based). >>> >>> The issue with pre-commit hooks is that they are run after all data is >>> transferred - so if I commit loads of data, and accidentally leave the >>> banned buildlog.htm file in... I'll find out about it after half an >>> hour's commit.. and have to repeat the process. >> >> No - there are two different hooks, for precisely this reason. >> pre-commit runs before all the file contents are transferred, and >> start-commit after all the file contents are transferred. > > Er... no. > > 'start-commit' runs before any files are transferred. It can't be used to > fail a commit based on any information that comes from the commit's tree > delta content payload. > > 'pre-commit' runs just before the commit transaction is promoted into a > revision, and can be used to block commits based on the content payload. > But only after the whole payload is transmitted to the server. In other words, I think you were essentially correct about the two-hook system, Julian -- you just had the hooks switched. But regardless, the two-hook system still fails Andrew's particular enforcement requirements (which are quite common). -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Bikeshed: configuration override order
On 08/10/2010 12:15 PM, Julian Foad wrote: > On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote: >>> Summary... >>> >>> There are two issues here... >>> >>> 1. The repo admin wants to enforce what is commited to their repo. >> This >>> exists with scripts but common request can be made inherient repo >> settings >>> (probably need to be path based). >>> >> >> The issue with pre-commit hooks is that they are run after all data is >> transferred - so if I commit loads of data, and accidentally leave the >> banned buildlog.htm file in... I'll find out about it after half an >> hour's commit.. and have to repeat the process. > > No - there are two different hooks, for precisely this reason. > pre-commit runs before all the file contents are transferred, and > start-commit after all the file contents are transferred. Er... no. 'start-commit' runs before any files are transferred. It can't be used to fail a commit based on any information that comes from the commit's tree delta content payload. 'pre-commit' runs just before the commit transaction is promoted into a revision, and can be used to block commits based on the content payload. But only after the whole payload is transmitted to the server. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
RE: Bikeshed: configuration override order
On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote: > > Summary... > > > > There are two issues here... > > > > 1. The repo admin wants to enforce what is commited to their repo. > This > > exists with scripts but common request can be made inherient repo > settings > > (probably need to be path based). > > > > The issue with pre-commit hooks is that they are run after all data is > transferred - so if I commit loads of data, and accidentally leave the > banned buildlog.htm file in... I'll find out about it after half an > hour's commit.. and have to repeat the process. No - there are two different hooks, for precisely this reason. pre-commit runs before all the file contents are transferred, and start-commit after all the file contents are transferred. - Julian [...]
RE: Bikeshed: configuration override order
> Summary... > > There are two issues here... > > 1. The repo admin wants to enforce what is commited to their repo. This > exists with scripts but common request can be made inherient repo settings > (probably need to be path based). > The issue with pre-commit hooks is that they are run after all data is transferred - so if I commit loads of data, and accidentally leave the banned buildlog.htm file in... I'll find out about it after half an hour's commit.. and have to repeat the process. It's not that major an issue but repo-set config would fix it. Auto-props is a more tricky problem that would just be nicely solved by telling the clients what settings to use. > 2. The admins want to simplify config for clients committing to repos that > have various enforcements made (see item 1) without needing to deal with > distirbuting client config files or what have you. This is the biggie - one remote worker decided he didn't have to read all the email I sent him on how to set up svn, and ended up committing 2 Gb of crud to my lovely repository. We have a pre-commit hook for all file extensions now. Perhaps the ideal (and easiest) way to resolve all this is to have the repo inform the client of mandatory settings that it expects to be set, and perhaps optional ones, and either automatically download a new set of configs to the client, or have the client fail until its config is in compliance with the repo's configuration settings. A new option could be added to the client to download and use the config from the repo. This could be made automatic, every time the client runs a repo-contacting command, it gets a hash or guid from the server that describes the config, and if that doesn't match what the client has, the client can run the config-download in the background (and then re-try the command it was trying to do). Perhaps allow the client to store multiple config files and use the one that matches the repo, along with the default one that we currently have. The server config can then only set the bits it wants, missing config options are used from the default. There's scope in there for the client to download the repo's chosen settings, and then override them anyway. There's scope for the repo to mandate a few options, giving the client a choice of going to play elsewhere or accept the restrictions. Anyway, that's my thoughts on the subject. Repo-driven config, even if its just an easy way to download a new set to the client instead of the email 'use this file, or use this registry script' is a huge step forward. Andy
RE: Bikeshed: configuration override order
> Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200: > > On 07.08.2010 12:44, Daniel Shahaf wrote: > >> If corporations want to have configuration override, fine. > >> > >> But I want a way to disable that completely. I don't > necessarily want to > >> allow a random sourceforge repository to control my auto-props > settings for > >> a wc of that repository. > > > > Maybe a stupid question: why not? > > Why don't I let ezmlm configure my mailer's "use html?" setting? > > If I run with use-server-config=ask, I might accept the prompt most > of the > time. But, ultimately, it's software I run on my computer, and I > should > have the final say over what configuration it runs with.[1] > > I suggest the following: > > * one can say "don't honor the server's suggestions" without > recompiling the client > > * one cannot make the client dishonor the suggestions *while > reporting that > it shall honor them* without recompiling. > > This way the server can rely on the self-report (and could even > refuse the > checkout if the self-report says "I will dishonor"). > > > I mean, if the developers of that project agree on certain rules > and > > decide to enforce them, shouldn't you also follow those rules if > you use > > I agree with stsp's point elsethread: if it's truly project > configuration, > it doesn't belong in ~/.subversion/. > > > that repository/wc? Especially if you have commit access there, > it would > > be very bad if you would commit something that would break those > rules. > > > > No, it won't be "very bad". It will mean I have to make another > commit to > fix the broken auto-props. > A repository administrator already has a way to enforce stuff like this via pre-commit hooks. Isn't that satisfactory. Wouldn't having repository/service specified settings just make it easier for devs so they don't have to worry about stuff like this to match every repository they deal with? Perhaps make enforcing certain auto-props and other possible client settings that affect what is more of a config thing rather than needing to write hook scripts is enough. Summary... There are two issues here... 1. The repo admin wants to enforce what is commited to their repo. This exists with scripts but common request can be made inherient repo settings (probably need to be path based). 2. The admins want to simplify config for clients committing to repos that have various enforcements made (see item 1) without needing to deal with distirbuting client config files or what have you. If these remain separate there is not way a client could over ride the repo admins whishes even if they did build there own client exe that overrode any repo config since it would be enforced via item 1. BOb
Re: Bikeshed: configuration override order
On Sat, 2010-08-07 at 07:58 -0400, Daniel Shahaf wrote: > Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200: > > On 07.08.2010 12:44, Daniel Shahaf wrote: > >> If corporations want to have configuration override, fine. > >> > >> But I want a way to disable that completely. I don't necessarily want to > >> allow a random sourceforge repository to control my auto-props settings for > >> a wc of that repository. > > > > Maybe a stupid question: why not? > > Why don't I let ezmlm configure my mailer's "use html?" setting? I think he was asking for an answer specifically relating to auto-props, not an answer about configuration in general. There's not generally a lot of room for individual disagreement about what auto-props should be for a given project. 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. Note that there's no general extension of the config framework here, no whitelisting or blacklisting, no override settings. Invent a mechanism for getting repository configuration from the server and apply it to the specific use cases in (1), falling back to client configuration as a legacy mechanism.
Re: Bikeshed: configuration override order
Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200: > On 07.08.2010 12:44, Daniel Shahaf wrote: >> If corporations want to have configuration override, fine. >> >> But I want a way to disable that completely. I don't necessarily want to >> allow a random sourceforge repository to control my auto-props settings for >> a wc of that repository. > > Maybe a stupid question: why not? Why don't I let ezmlm configure my mailer's "use html?" setting? If I run with use-server-config=ask, I might accept the prompt most of the time. But, ultimately, it's software I run on my computer, and I should have the final say over what configuration it runs with.[1] I suggest the following: * one can say "don't honor the server's suggestions" without recompiling the client * one cannot make the client dishonor the suggestions *while reporting that it shall honor them* without recompiling. This way the server can rely on the self-report (and could even refuse the checkout if the self-report says "I will dishonor"). > I mean, if the developers of that project agree on certain rules and > decide to enforce them, shouldn't you also follow those rules if you use I agree with stsp's point elsethread: if it's truly project configuration, it doesn't belong in ~/.subversion/. > that repository/wc? Especially if you have commit access there, it would > be very bad if you would commit something that would break those rules. > No, it won't be "very bad". It will mean I have to make another commit to fix the broken auto-props. > Stefan > [1] That's why we parse ~/.subversion/ *after* /etc/subversion/ and why mailers can be configured to prompt before honoring the Reply-To header.
Re: Bikeshed: configuration override order
On 07.08.2010 12:44, Daniel Shahaf wrote: If corporations want to have configuration override, fine. But I want a way to disable that completely. I don't necessarily want to allow a random sourceforge repository to control my auto-props settings for a wc of that repository. Maybe a stupid question: why not? I mean, if the developers of that project agree on certain rules and decide to enforce them, shouldn't you also follow those rules if you use that repository/wc? Especially if you have commit access there, it would be very bad if you would commit something that would break those rules. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Bikeshed: configuration override order
If corporations want to have configuration override, fine.
But I want a way to disable that completely. I don't necessarily want to
allow a random sourceforge repository to control my auto-props settings for
a wc of that repository.
So. We could have an allow-repos-config switch (parallel to the existing
allow-plaintext-passwords switch), which could be boolean or three-value
(yes/no/ask).
Daniel
(And if the switch is disabled but the repos wants to dictate client-side
config anyway? We could refuse the checkout (corp repos) or allow it anyway
with a warning (sourceforge repos).)
Hyrum K. Wright wrote on Fri, Aug 06, 2010 at 13:23:39 -0500:
> On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato wrote:
> > On 08/06/2010 01:50 PM, Hyrum K. Wright wrote:
> >> I'm doing some more thinking about repository-dictated configuration,
> >> and one of the things I'd like some discussion on is the order of
> >> configuration overrides. The consensus is that the repository can not
> >> be sure that it's dictated configuration is received and respected by
> >> the client, so it should treat whatever config it sends as purely
> >> suggestive. We currently have several (implemented or proposed)
> >> sources for configuration information, and I think they should be
> >> searched in the following order:
> >>
> >> * Client site-wide configuration (/etc/subversion)
> >> * Client user-specific configuration (~/subversion, 'svn --config-dir')
> >> * Repository-dictated configuration (as described above)
> >> * Explicit configuration supplied by the client application
> >> ('svn --config-option', or Eclipse configuration options)
> >>
> >> Not every location contains every bit of config, of course, but in the
> >> case of conflicts, the most recent encountered value sticks. In other
> >> words, a client could override repository-dictated configuration
> >> options by using 'svn --config-option', or the (as yet unimplemented)
> >> equivalent facility for other API consumers.
> >>
> >> Thoughts?
> >
> > It seems to me like, if we search the list above in the order presented (as
> > you suggest), we pretty much get the worst possible scenario. Maybe it's a
> > wording thing, though. (I'm thinking search-and-stop-on-first-find ...
> > maybe you mean overlay/overwrite configurations in this order, then search
> > the merged results?)
>
> I mean the latter: read a config, overwrite any previous values,
> repeat. This is how the current system is set up today, I believe (it
> uses apr hashes to store the configuration, and just blindly sets the
> values it finds, leading the most recent found to be the functional
> value).
>
> > Whatever you meant, the corporate customers I've spoken with understand
> > that, so long as they are using open source Subversion clients, anyone can
> > theoretically modify their client to change its behavior. But on the
> > assumption that that is a rare case, they want Subversion to try to treat
> > the repos-dictated config as more than merely suggestive. In other words,
> > they want to be able to reasonably expect that in order to get behavior that
> > opposes the repos-dictated configuration, the user *must* have modified
> > their client or used a client that doesn't honor Subversion's design in this
> > respect.
> >
> > In the past, I've proposed the idea of two repos-dictated configuration
> > sets: one that has the ultimately authority and cannot be overridden
> > without library changes, one that sits in about the slot you've described
> > above.
>
> I dunno. I think that may be a bit too complex for a first pass, and
> I think that adding a requirement to hack the library doesn't really
> add any value, other than obfuscation. The obfuscated approach may
> fool some people, but if they really want to override, they are going
> to do it. I'd rather accomplish that via the parsing order than
> hacking the library (having to specify 'svn --config-option', seems
> like a reasonable barrier).
>
> I just wrote that and then read Greg Hudson's mail elsethread, which
> makes me wonder if we need three piles:
> * always override from server
> * possibly override from server
> * never override from server
>
> -Hyrum
Re: Bikeshed: configuration override order
Stefan Sperling wrote on Fri, Aug 06, 2010 at 21:51:37 +0200: > Why do we have settings in the individual client config that all users > would want to share anyway? > > So maybe having auto-props in the config is part of the problem? What about > having an svn:auto-props property at the parent directory, specifying > autoconf settings for its direct children? Agreed. > Too inconvenient to set up due to lack of recursive property support? > Would 'svn propset -R' do to configure auto-props for an entire subtree > like '/trunk'? Or do we want something like "this is a branch root" property? Or do we want some "look in parent" value for svn:auto-props? for i in $subdirs_of_trunk; do svn propset --symlink svn:auto-props ../ $i done (and then, what happens if you checkout a proper subfolder of trunk --- e.g., ^/trunk/subversion --- without checkouting its parent, and attempt a propset? Not unsolvable, but needs to be thought of.) > Once those properties were set up and configured, users > could mostly forget about auto-props unless the default auto-props need > to be changed. Not whenever they start working on a different client > computer, as they do today. Yes.
Re: Bikeshed: configuration override order
On Fri, Aug 06, 2010 at 02:28:11PM -0400, Bob Archer wrote: > But really why do people want this. I think it is so some settings like > auto-props and other things that need to be set for a specific project will > take place without having to distribute a config or send an email with "make > sure you add this to your config" type of warning from a pre-commit hook that > notices certain properties are missing for certain file types. > Auto-props are one killer app. Another one is save-plaintext-passwords = no. It's documented in trunk/notes/feedback/cmpilato-user-calls: * Server-side control of client-side behaviors: Admins want to know that every Subversion user has the same configuration for simple things like auto-props rules, and want to be able to control things like our "store-plaintext-passwords" toggles remotely in a way that's not easily override-able. Looking at the current set of variables we have in ~/.subversion/config, there are a few that set up Subversion to behave according to a user's individual preference, and don't affect other users: editor-cmd, diff-cmd, diff3-cmd, merge-tool-cmd, diff-extensions, ssh, no-unlock, interactive-conflicts But we also have these which should probably be configured similar for all users working on the same project anyway: global-ignores, log-encoding, use-commit-times, mime-types-file, preserved-conflict-file-exts, enable-auto-props I haven't looked at the 'servers' file. I'm not against adding a repository-configuration feature if we really need it. But before thinking about implementation details of this feature, such as how one type of configuration setting can override another, we should clearly define the use cases that require repository-dictated configuration. And ask ourselves and our users whether repository-dictated configuration is really the best way of solving these problem. And try to come up with alternative ways of solving them. Why do we have settings in the individual client config that all users would want to share anyway? For instance, regarding auto-props I'm not really sure I understand why users have to set them in the config in the first place. It makes this feature quite inconvenient to use in my opinion. At least I've never been bothered enough to enable it for every-day use. It would be much nicer if Subversion simply set properties like svn:eol-style up according to the project's convention, leaving me with the possibility to override the default before commit. So maybe having auto-props in the config is part of the problem? What about having an svn:auto-props property at the parent directory, specifying autoconf settings for its direct children? Too inconvenient to set up due to lack of recursive property support? Would 'svn propset -R' do to configure auto-props for an entire subtree like '/trunk'? Once those properties were set up and configured, users could mostly forget about auto-props unless the default auto-props need to be changed. Not whenever they start working on a different client computer, as they do today. So maybe defining additional properties in the svn: namespace that allow project-wide configuration of Subversion's behaviour would make sense. svn:global-ignores, svn:log-encoding, svn:use-commit-times, svn:mime-types-file, svn:preserved-conflict-file-exts, svn:auto-props The only question left then is about how these properties would be scoped, i.e. where do you set them and what do they affect. The store-plaintext-passwords could also be addressed with a configuration switch that turned off plaintext password storage at compile time. Then you have to compile your own client to use the feature. Or we just flip the default from 'ask' to 'no', and let users who really want their passwords saved in plaintext take an extra step to enable the behaviour. I think the current default behaviour (prompting) is good middle-ground, but it's possible that in some environments administrators really do not want users to have a choice in the matter by default. Yet users who really want to be disobedient and save their passwords in plaintext will always be able to do so somehow, no matter what we do. We can't solve a social problem. Depending on how admins manage user software, they might be able to install a system-wide configuration file on their user's machines that tells all Subversion clients to say 'no' by default. This is done on OpenBSD when Subversion is installed from the OS-provided binary package, for instance: $ cat /etc/subversion/servers # $OpenBSD: servers,v 1.1 2009/08/25 10:26:20 stsp Exp $ [global] store-plaintext-passwords=no $ Stefan
RE: Bikeshed: configuration override order
> On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson > wrote: > > On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote: > >> I'm doing some more thinking about repository-dictated > configuration, > > > > I get nervous when I see people talk about repository-dictated > > configuration as an extension of the general configuration > framework. > > > > There are a lot of things a repository should not be able to > configure > > for trust reasons--in particular, what commands the client runs. > When > > you check out material from a repository, you are not handing > over the > > keys to your machine or account, just retrieving content. In > fact, I > > think there are only a few specific configuration variables which > a > > repository should be able to influence, such as mime-type > recognition. > > Agree with the general point, but it raises another point: which > values are acceptable for overriding? Are they hardcoded or > configurable (if configurable, that kinda defeats the point, since > they'd have to be configured locally)? White list? Black list? > > Would a hard-coded list be something that depends on application > (corporate vs. open source vs. some other deployment)? > > -Hyrum As I said in a previous email, you might want to consider looking at the asp.net configuration and how that is done. They have a configuration hierarchy and inheritence. You can specify the scope of the configuration items and also you can restrict inheritence on certain items. http://msdn.microsoft.com/en-us/library/ms178685.aspx Of course, since svn is open source... it would be possible to create a client that would ignore inheritance restrictions with a few // characters in the source code. I guess an enterprise client would want to compile there own client and sign it and only allow signed clients to access the repository or something to mitigate that kind of stuff. But really why do people want this. I think it is so some settings like auto-props and other things that need to be set for a specific project will take place without having to distribute a config or send an email with "make sure you add this to your config" type of warning from a pre-commit hook that notices certain properties are missing for certain file types. BOb
Re: Bikeshed: configuration override order
On 06.08.2010 20:18, Hyrum K. Wright wrote: > On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson wrote: > >> On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote: >> >>> I'm doing some more thinking about repository-dictated configuration, >>> >> I get nervous when I see people talk about repository-dictated >> configuration as an extension of the general configuration framework. >> >> There are a lot of things a repository should not be able to configure >> for trust reasons--in particular, what commands the client runs. When >> you check out material from a repository, you are not handing over the >> keys to your machine or account, just retrieving content. In fact, I >> think there are only a few specific configuration variables which a >> repository should be able to influence, such as mime-type recognition. >> > Agree with the general point, but it raises another point: which > values are acceptable for overriding? Are they hardcoded or > configurable (if configurable, that kinda defeats the point, since > they'd have to be configured locally)? White list? Black list? > > Would a hard-coded list be something that depends on application > (corporate vs. open source vs. some other deployment)? > I'd suggest a hard-coded list in libsvn_client. The type of deployment is irrelevant, because anyone can hack the source to suit their needs. The important bit is that we put a safe default whitelist into the code we publish. -- Brane
Re: Bikeshed: configuration override order
On 06.08.2010 20:13, Greg Hudson wrote: > On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote: > >> I'm doing some more thinking about repository-dictated configuration, >> > I get nervous when I see people talk about repository-dictated > configuration as an extension of the general configuration framework. > > There are a lot of things a repository should not be able to configure > for trust reasons--in particular, what commands the client runs. When > you check out material from a repository, you are not handing over the > keys to your machine or account, just retrieving content. In fact, I > think there are only a few specific configuration variables which a > repository should be able to influence, such as mime-type recognition. > That was my concern, too -- and those settings should only ever take effect on working copies of that repository. Which implies that you have to re-evaluate them for every switched entry or external or embedded working copy. -- Brane
Re: Bikeshed: configuration override order
On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato wrote:
> On 08/06/2010 01:50 PM, Hyrum K. Wright wrote:
>> I'm doing some more thinking about repository-dictated configuration,
>> and one of the things I'd like some discussion on is the order of
>> configuration overrides. The consensus is that the repository can not
>> be sure that it's dictated configuration is received and respected by
>> the client, so it should treat whatever config it sends as purely
>> suggestive. We currently have several (implemented or proposed)
>> sources for configuration information, and I think they should be
>> searched in the following order:
>>
>> * Client site-wide configuration (/etc/subversion)
>> * Client user-specific configuration (~/subversion, 'svn --config-dir')
>> * Repository-dictated configuration (as described above)
>> * Explicit configuration supplied by the client application
>> ('svn --config-option', or Eclipse configuration options)
>>
>> Not every location contains every bit of config, of course, but in the
>> case of conflicts, the most recent encountered value sticks. In other
>> words, a client could override repository-dictated configuration
>> options by using 'svn --config-option', or the (as yet unimplemented)
>> equivalent facility for other API consumers.
>>
>> Thoughts?
>
> It seems to me like, if we search the list above in the order presented (as
> you suggest), we pretty much get the worst possible scenario. Maybe it's a
> wording thing, though. (I'm thinking search-and-stop-on-first-find ...
> maybe you mean overlay/overwrite configurations in this order, then search
> the merged results?)
I mean the latter: read a config, overwrite any previous values,
repeat. This is how the current system is set up today, I believe (it
uses apr hashes to store the configuration, and just blindly sets the
values it finds, leading the most recent found to be the functional
value).
> Whatever you meant, the corporate customers I've spoken with understand
> that, so long as they are using open source Subversion clients, anyone can
> theoretically modify their client to change its behavior. But on the
> assumption that that is a rare case, they want Subversion to try to treat
> the repos-dictated config as more than merely suggestive. In other words,
> they want to be able to reasonably expect that in order to get behavior that
> opposes the repos-dictated configuration, the user *must* have modified
> their client or used a client that doesn't honor Subversion's design in this
> respect.
>
> In the past, I've proposed the idea of two repos-dictated configuration
> sets: one that has the ultimately authority and cannot be overridden
> without library changes, one that sits in about the slot you've described
> above.
I dunno. I think that may be a bit too complex for a first pass, and
I think that adding a requirement to hack the library doesn't really
add any value, other than obfuscation. The obfuscated approach may
fool some people, but if they really want to override, they are going
to do it. I'd rather accomplish that via the parsing order than
hacking the library (having to specify 'svn --config-option', seems
like a reasonable barrier).
I just wrote that and then read Greg Hudson's mail elsethread, which
makes me wonder if we need three piles:
* always override from server
* possibly override from server
* never override from server
-Hyrum
Re: Bikeshed: configuration override order
On 06.08.2010 19:50, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides. The consensus is that the repository can not
be sure that it's dictated configuration is received and respected by
the client, so it should treat whatever config it sends as purely
suggestive. We currently have several (implemented or proposed)
sources for configuration information, and I think they should be
searched in the following order:
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-dir')
* Repository-dictated configuration (as described above)
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
Not every location contains every bit of config, of course, but in the
case of conflicts, the most recent encountered value sticks. In other
words, a client could override repository-dictated configuration
options by using 'svn --config-option', or the (as yet unimplemented)
equivalent facility for other API consumers.
I think that repository-dictated configurations should override client
configs. This is what I think most corporations would expect.
Maybe there could be two client configs: one used as a default if no
corresponding repo-dictated config is available, and then one to
explicitly override the repo-dictated config.
Something like this:
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-dir')
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
* Repository-dictated configuration (as described above)
* forced configuration by the client (e.g., svn --override-repo-config)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/>The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Bikeshed: configuration override order
[Hyrum K. Wright] > We currently have several (implemented or proposed) sources for > configuration information, and I think they should be searched in the > following order: Ah, and what about things like global-ignores or auto-props, where you can set multiple "properties" per option? If the repository says *.c = svn:eol-style=native and my ~/.subversion/config says *.c = svn:mime-type=text/plain then what will happen? What should happen? Also, can one config source delete an auto-props glob from elsewhere? Peter
Re: Bikeshed: configuration override order
On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson wrote: > On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote: >> I'm doing some more thinking about repository-dictated configuration, > > I get nervous when I see people talk about repository-dictated > configuration as an extension of the general configuration framework. > > There are a lot of things a repository should not be able to configure > for trust reasons--in particular, what commands the client runs. When > you check out material from a repository, you are not handing over the > keys to your machine or account, just retrieving content. In fact, I > think there are only a few specific configuration variables which a > repository should be able to influence, such as mime-type recognition. Agree with the general point, but it raises another point: which values are acceptable for overriding? Are they hardcoded or configurable (if configurable, that kinda defeats the point, since they'd have to be configured locally)? White list? Black list? Would a hard-coded list be something that depends on application (corporate vs. open source vs. some other deployment)? -Hyrum
Re: Bikeshed: configuration override order
On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote: > I'm doing some more thinking about repository-dictated configuration, I get nervous when I see people talk about repository-dictated configuration as an extension of the general configuration framework. There are a lot of things a repository should not be able to configure for trust reasons--in particular, what commands the client runs. When you check out material from a repository, you are not handing over the keys to your machine or account, just retrieving content. In fact, I think there are only a few specific configuration variables which a repository should be able to influence, such as mime-type recognition.
Re: Bikeshed: configuration override order
On 08/06/2010 01:50 PM, Hyrum K. Wright wrote:
> I'm doing some more thinking about repository-dictated configuration,
> and one of the things I'd like some discussion on is the order of
> configuration overrides. The consensus is that the repository can not
> be sure that it's dictated configuration is received and respected by
> the client, so it should treat whatever config it sends as purely
> suggestive. We currently have several (implemented or proposed)
> sources for configuration information, and I think they should be
> searched in the following order:
>
> * Client site-wide configuration (/etc/subversion)
> * Client user-specific configuration (~/subversion, 'svn --config-dir')
> * Repository-dictated configuration (as described above)
> * Explicit configuration supplied by the client application
>('svn --config-option', or Eclipse configuration options)
>
> Not every location contains every bit of config, of course, but in the
> case of conflicts, the most recent encountered value sticks. In other
> words, a client could override repository-dictated configuration
> options by using 'svn --config-option', or the (as yet unimplemented)
> equivalent facility for other API consumers.
>
> Thoughts?
It seems to me like, if we search the list above in the order presented (as
you suggest), we pretty much get the worst possible scenario. Maybe it's a
wording thing, though. (I'm thinking search-and-stop-on-first-find ...
maybe you mean overlay/overwrite configurations in this order, then search
the merged results?)
Whatever you meant, the corporate customers I've spoken with understand
that, so long as they are using open source Subversion clients, anyone can
theoretically modify their client to change its behavior. But on the
assumption that that is a rare case, they want Subversion to try to treat
the repos-dictated config as more than merely suggestive. In other words,
they want to be able to reasonably expect that in order to get behavior that
opposes the repos-dictated configuration, the user *must* have modified
their client or used a client that doesn't honor Subversion's design in this
respect.
In the past, I've proposed the idea of two repos-dictated configuration
sets: one that has the ultimately authority and cannot be overridden
without library changes, one that sits in about the slot you've described above.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
RE: Bikeshed: configuration override order
> * Client site-wide configuration (/etc/subversion)
> * Client user-specific configuration (~/subversion, 'svn --config-
> dir')
> * Repository-dictated configuration (as described above)
> * Explicit configuration supplied by the client application
>('svn --config-option', or Eclipse configuration options)
>
> Not every location contains every bit of config, of course, but in
> the
> case of conflicts, the most recent encountered value sticks. In
> other
> words, a client could override repository-dictated configuration
> options by using 'svn --config-option', or the (as yet
> unimplemented)
> equivalent facility for other API consumers.
>
> Thoughts?
Hmm... so you are saying that repository settings will override locally
configured settings but not CLI specified settings? Why? That seems a bit
backward to me. I would expect:
* Repository-dictated configuration (as described above)
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-
dir')
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
Can these settings be path specific in the repository? What happens if I have
checked-out a sub-path... I'm not sure if you plan on implementing this as a
config file a user can check into svn or as properties like the keyword stuff
or were you thinking that these is info that will be passed from the server to
the client when requested?
One other option, an idea that ASP.Net uses for its config settings is the
ability to specify at what level a setting can be overridden.
BOb
