You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2012/02/23 16:32:35 UTC
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
On Wed, Feb 22, 2012 at 11:13 AM, <cm...@tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4124
> Issue #|4124
> Summary|Give servers sufficient means to disallow commits from
> | clients based on version numbers
> Component|subversion
> Version|1.7.x
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|ENHANCEMENT
> Priority|P3
> Subcomponent|libsvn_ra
> Assigned to|issues@subversion
> Reported by|cmpilato
>
>
>
>
>
>
> ------- Additional comments from cmpilato@tigris.org Wed Feb 22 08:13:31 -0800 2012 -------
> I'm seeing more and more requests from admins (in public and private channels)
> seeking ways to ensure that the users of their repositories are committing with
> a particular pedigree of client, namely one that meets some version number
> threshold.
>
> In the past, we frowned on the idea of such version-number-centric mechanisms
> for allowing/denying commit access, citing the ease with which the value can be
> spoofed and opting instead to push for capabilities strings that carried more
> specific information ("supports merge tracking", or "supports atomic revision
> property changes", etc.). The problem we are seeing now is two-fold:
>
> 1. As a community, we the developers aren't particularly good at identifying
> which changes that we make to the client codebase are of the sort that justify a
> new capability string. So, we've been extremely conservative about adding them,
> even though practically each new merge-tracking related bugfix is likely a
> reason to wish clients weren't using un-fixed clients.
>
> 2. As implied above, there are in reality many more such interesting changes
> than we wish to individually track. I mean, do we *really* want to see the
> likes of "merginfo, atomic-revprops, fix-for-issue-5911,
> fix-for-the-commit-part-of-issue-5621, subtree-mergeinfo-minimized,
> subtree-mergeinfo-minimized-round-2, ..."?
>
> Why not just give users what they want? A capability string (or comparable
> mechanism) that carries the client's version number, for use with start-commit
> hooks in allowing/denying clients which don't meet the administrator's quality
> requirements?
Mike,
+1 to this enhancement. One question though, are you envisioning a
new "capability" for each minor release or for each patch release? I
assume the latter, but that's not entirely clear from the issue
writeup.
Paul
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/23/2012 10:24 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Thu, Feb 23, 2012 at 10:48:12 -0500:
>> As Mark indicated, I was *not* thinking about a different capability per
>> release -- just a single, changing one. My suggested syntax was to be
>> "client-version=1.7.3", establishing precedent for the use of the equal sign
>
> What client-version would dev builds report?
First guess: SVN_VER_NUMBER.
If we feel we need higher granularity, we can go with a full-fledged
SVN_VERSION, but that *might* force us away from using the existing
capabilities mechanism. (I don't know what restrictions it has regarding
the use of whitespace.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [Issue 4124] New - Give servers sufficient means to disallow commits from clients based on version numbers
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> Markus Schaber wrote:
>> There are two other cases we should define a rule for:
>>
>> 1) Clients like SharpSVN or TortoiseSVN, or distribution builds, when they
>> include their own patches, or backported patches which were not officially part
>> of that release. [...]
>>
>> 2) Clients based on alternative implementations like SvnKit (is there any
>> other?).
>
> Solve both by adding a "capability" for the short client name?
>
> client-version=1.7.3 client-client=tortoisesvn
> client-version=1.7.3 client-client=svnkit
For years, as I understand, people have been using the "user-agent" string that's transmitted over HTTP
connections to identify the client when they want this sort of ability
to reject certain client versions. I assume the main problem with the
"user-agent" string is it's not available on the server in a consistent
way for all RA protocols. It would be better if it were available in a
consistent way, and an obvious way is making it available to a hook
script, as C-Mike's proposal says.
However,
the exact format of the user-agent string has been left to the
discretion of client authors. Examples from a web search:
SVN/1.0.0 neon/0.24.4
SVN/1.0.1 (dev build) neon/0.24.4
SVN/1.6.5 (r38866)/TortoiseSVN-1.6.5.16974
SVN/1.7.0-dev neon/0.29.6
SVN/1.7.2 neon/0.29.6
SVN/1.7.2/TortoiseSVN-1.7.3.22386 neon/0.29.6
SVN/1.7.2 SVNKit/1.7.0-alpha2 (http://svnkit.com/) t20120112_2133
SVN/1.8.0-dev serf/2.0.0
So can we take a clue from those examples and define something perhaps a little more formally structured but still with enough flexibility for clients to specify their own version string as well as the version of SVN libraries that they're actually or nominally based on?
- Julian
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Markus Schaber wrote on Fri, Feb 24, 2012 at 08:09:30 +0000:
> Hi, Daniel,
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Shahaf [mailto:danielsh@elego.de]
>
> >C. Michael Pilato wrote on Thu, Feb 23, 2012 at 10:48:12 -0500:
> >> On 02/23/2012 10:35 AM, Mark Phippard wrote:
> >> > On Thu, Feb 23, 2012 at 10:32 AM, Paul Burba <pt...@gmail.com> wrote:
> >> >>> Why not just give users what they want? A capability string (or
> >> >>> comparable
> >> >>> mechanism) that carries the client's version number, for use with
> >> >>> start-commit hooks in allowing/denying clients which don't meet
> >> >>> the administrator's quality requirements?
> >> >>
> >> >> Mike,
> >> >>
> >> >> +1 to this enhancement. One question though, are you envisioning a
> >> >> new "capability" for each minor release or for each patch release?
> >> >> I assume the latter, but that's not entirely clear from the issue
> >> >> writeup.
> >> >
> >> > I would suggest something easily parseable like "ClientVersion-1.7.3"
> >> >
> >> > I would assume it would be a single string that contained the exact
> >> > version number and it would be up to the hook script to do something
> >> > with it.
> >>
> >> As Mark indicated, I was *not* thinking about a different capability
> >> per release -- just a single, changing one. My suggested syntax was
> >> to be "client-version=1.7.3", establishing precedent for the use of
> >> the equal sign
> >
> >What client-version would dev builds report?
>
> There are two other cases we should define a rule for:
>
> 1) Clients like SharpSVN or TortoiseSVN, or distribution builds, when they include their own patches, or backported patches which were not officially part of that release. Especially Debian tends to prefer backporting of fixes over updating to new releases.
>
> 2) Clients based on alternative implementations like SvnKit (is there any other?).
>
Solve both by adding a "capability" for the short client name?
client-version=1.7.3 client-client=tortoisesvn
client-version=1.7.3 client-client=svnkit
> Best regards
>
> Markus Schaber
> --
> ___________________________
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
>
> Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>
>
AW: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Daniel,
-----Ursprüngliche Nachricht-----
Von: Daniel Shahaf [mailto:danielsh@elego.de]
>C. Michael Pilato wrote on Thu, Feb 23, 2012 at 10:48:12 -0500:
>> On 02/23/2012 10:35 AM, Mark Phippard wrote:
>> > On Thu, Feb 23, 2012 at 10:32 AM, Paul Burba <pt...@gmail.com> wrote:
>> >>> Why not just give users what they want? A capability string (or
>> >>> comparable
>> >>> mechanism) that carries the client's version number, for use with
>> >>> start-commit hooks in allowing/denying clients which don't meet
>> >>> the administrator's quality requirements?
>> >>
>> >> Mike,
>> >>
>> >> +1 to this enhancement. One question though, are you envisioning a
>> >> new "capability" for each minor release or for each patch release?
>> >> I assume the latter, but that's not entirely clear from the issue
>> >> writeup.
>> >
>> > I would suggest something easily parseable like "ClientVersion-1.7.3"
>> >
>> > I would assume it would be a single string that contained the exact
>> > version number and it would be up to the hook script to do something
>> > with it.
>>
>> As Mark indicated, I was *not* thinking about a different capability
>> per release -- just a single, changing one. My suggested syntax was
>> to be "client-version=1.7.3", establishing precedent for the use of
>> the equal sign
>
>What client-version would dev builds report?
There are two other cases we should define a rule for:
1) Clients like SharpSVN or TortoiseSVN, or distribution builds, when they include their own patches, or backported patches which were not officially part of that release. Especially Debian tends to prefer backporting of fixes over updating to new releases.
2) Clients based on alternative implementations like SvnKit (is there any other?).
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Thu, Feb 23, 2012 at 10:48:12 -0500:
> On 02/23/2012 10:35 AM, Mark Phippard wrote:
> > On Thu, Feb 23, 2012 at 10:32 AM, Paul Burba <pt...@gmail.com> wrote:
> >>> Why not just give users what they want? A capability string (or comparable
> >>> mechanism) that carries the client's version number, for use with start-commit
> >>> hooks in allowing/denying clients which don't meet the administrator's quality
> >>> requirements?
> >>
> >> Mike,
> >>
> >> +1 to this enhancement. One question though, are you envisioning a
> >> new "capability" for each minor release or for each patch release? I
> >> assume the latter, but that's not entirely clear from the issue
> >> writeup.
> >
> > I would suggest something easily parseable like "ClientVersion-1.7.3"
> >
> > I would assume it would be a single string that contained the exact
> > version number and it would be up to the hook script to do something
> > with it.
>
> As Mark indicated, I was *not* thinking about a different capability per
> release -- just a single, changing one. My suggested syntax was to be
> "client-version=1.7.3", establishing precedent for the use of the equal sign
What client-version would dev builds report?
> for name/value pairs.
+0
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/23/2012 10:35 AM, Mark Phippard wrote:
> On Thu, Feb 23, 2012 at 10:32 AM, Paul Burba <pt...@gmail.com> wrote:
>>> Why not just give users what they want? A capability string (or comparable
>>> mechanism) that carries the client's version number, for use with start-commit
>>> hooks in allowing/denying clients which don't meet the administrator's quality
>>> requirements?
>>
>> Mike,
>>
>> +1 to this enhancement. One question though, are you envisioning a
>> new "capability" for each minor release or for each patch release? I
>> assume the latter, but that's not entirely clear from the issue
>> writeup.
>
> I would suggest something easily parseable like "ClientVersion-1.7.3"
>
> I would assume it would be a single string that contained the exact
> version number and it would be up to the hook script to do something
> with it.
As Mark indicated, I was *not* thinking about a different capability per
release -- just a single, changing one. My suggested syntax was to be
"client-version=1.7.3", establishing precedent for the use of the equal sign
for name/value pairs.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [Issue 4124] New - Give servers sufficient means to disallow
commits from clients based on version numbers
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Feb 23, 2012 at 10:32 AM, Paul Burba <pt...@gmail.com> wrote:
>> Why not just give users what they want? A capability string (or comparable
>> mechanism) that carries the client's version number, for use with start-commit
>> hooks in allowing/denying clients which don't meet the administrator's quality
>> requirements?
>
> Mike,
>
> +1 to this enhancement. One question though, are you envisioning a
> new "capability" for each minor release or for each patch release? I
> assume the latter, but that's not entirely clear from the issue
> writeup.
I would suggest something easily parseable like "ClientVersion-1.7.3"
I would assume it would be a single string that contained the exact
version number and it would be up to the hook script to do something
with it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/