You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2005/01/08 17:22:50 UTC
Request: make the user agent string a define
Hi,
A feature which is requested often on the TSVN mailing list is the
ability to check the client version in a pre-commit hook.
(the latest request was because they wanted to reject commits from TSVN
clients which don't have the bugtraq features implemented yet)
I've searched the mailing lists and found that this is already possible
if the repository is hosted on an Apache server.
(http://svn.haxx.se/dev/archive-2003-05/1680.shtml)
Then I looked at the source where that agent string is set/sent:
subversion/libsvn_ra_dav/session.c, line 659,660 (1.1.2 tag)
ne_set_useragent(sess, "SVN/" SVN_VERSION);
ne_set_useragent(sess2, "SVN/" SVN_VERSION);
As it is now, another client can't change that string to something else
(e.g. "TSVN/1.1.2"), so I'd like to request that this is changed into a
define (which of course defaults to "SVN/"SVN_VERSION) but can be
changed by a client when compiling/linking to the Subversion libs.
Better would be a new function to set that string (usefull for those
clients which use the precompiled language bindings).
Even better would be if Subversion would allow to set revprops with
every command that affects the repository. That way, a new revprop (e.g.
svn:user-agent) could be written every time. This would also have the
advantage that you could later check each revision and find out with
which client is was made. And of course it wouldn't be restricted to
Apache based repositories.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Max Bowsher <ma...@ukf.net> writes:
> I guess "SVN/x.y.z (some additional settable string)" would be OK.
"TortoiseSVN/x.y.z SVN/u.v.w" would be more in line with the
"CERN-LineMode/2.15 libwww/2.17b3" example in RFC 2616.
Re: Request: make the user agent string a define
Posted by Branko Čibej <br...@xbc.nu>.
steven.higgan wrote:
>Max Bowsher wrote:
>
>
>>Instead, pre-commit can check not for the version, but for the invalid
>>data, and reject *that*.
>>
>>
>
>Good point,
>
>I suppose for me it comes down to what is easier, is it easier to need to
>write code that sniffs what's coming down the pipe to ensure that it is
>properly encoded (something I haven't got a clue how to do). Or is it easier
>to check a 'user-agent' which would be much eaiser.
>
>
Much easier, but it wouldn't protect you from malicious clients that
fake the user-agent string, whereas checking the incoming data will
always work. So what's the point?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Request: make the user agent string a define
Posted by "steven.higgan" <st...@orcon.net.nz>.
Max Bowsher wrote:
> Instead, pre-commit can check not for the version, but for the invalid
> data, and reject *that*.
Good point,
I suppose for me it comes down to what is easier, is it easier to need to
write code that sniffs what's coming down the pipe to ensure that it is
properly encoded (something I haven't got a clue how to do). Or is it easier
to check a 'user-agent' which would be much eaiser.
---------------------------------------------------------------------------
Steven Higgan - 3rd Year B.I.T. Otago Polytechnic, Dunedin New Zealand
.net geek
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
Ivan-Assen Ivanov wrote:
>>> data). During the time in which you wait for a new server release, you
>>> can then only pray that all your users don't use that broken client
>>> anymore - not a very good scenario if you ask me.
>>
>> Or, you can implement appropriate checking in the pre-commit script.
>
> OK, so this is something I don't understand.
> How can you implement appropriate checking in the pre-commit script,
> if the pre-commit script doesn't have sufficient information to reason
> about it? Wasn't that the whole point of the original request of
> SteveKing, before you two got sidetracked into a theoritical
> discussion on client/server compatibility?
SteveKing wanted to check version in pre-commit, to protect against old
buggy clients from sending invalid data to the server.
I counter-proposed that version checking was undesirable, because it would
affect buggy clients even when sending correct data, and also affect clients
that would have been patched to avoid the bug.
Instead, pre-commit can check not for the version, but for the invalid data,
and reject *that*.
> To put it back to where it was: How can I, as a maintainer of a
> Subversion repository, and writer of a pre- and post-commit scripts,
> determine whether a particular commit attempt is coming from a user
> without the physical ability to adhere to the codebase standards
> established on this repository, (in this particular case, the
> requirement that all commits are related to issue numbers in the issue
> tracking system)?
Don't check whether the client has the capability, check whether the
incoming commit has the appropriate markings associating it with an issue
number.
> I can see how it is a good idea to _technically_ provide compatibility
> between various clients and servers. I fail to see how it is a good
> idea to explicitly forbid breaking compatibily as conscious decision
> on part of the server's administrator for _administrative_ reasons.
I'd rather help the administrator achieve the desired result (commits
conforming to certain policies), without needing to to break compatibility.
> What is the point of the user agent string anyway?
Not very much at all.
It exists only because such a thing is expected in HTTP.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Ivan-Assen Ivanov <iv...@gmail.com>.
> > data). During the time in which you wait for a new server release, you
> > can then only pray that all your users don't use that broken client
> > anymore - not a very good scenario if you ask me.
>
> Or, you can implement appropriate checking in the pre-commit script.
OK, so this is something I don't understand.
How can you implement appropriate checking in the pre-commit script,
if the pre-commit script doesn't have sufficient information to reason
about it? Wasn't that the whole point of the original request of
SteveKing, before you two got sidetracked into a theoritical
discussion on client/server compatibility?
To put it back to where it was: How can I, as a maintainer of a
Subversion repository, and writer of a pre- and post-commit scripts,
determine whether a particular commit attempt is coming from a user
without the physical ability to adhere to the codebase standards
established on this repository, (in this particular case, the
requirement that all commits are related to issue numbers in the issue
tracking system)?
I can see how it is a good idea to _technically_ provide compatibility
between various clients and servers. I fail to see how it is a good
idea to explicitly forbid breaking compatibily as conscious decision
on part of the server's administrator for _administrative_ reasons.
What is the point of the user agent string anyway?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 8, 2005, at 8:54 PM, Steven H @ orcon wrote:
> Max Bowsher wrote:
>
>> SteveKing wrote:
>>> During the time in which you wait for a new server release, you
>>> can then only pray that all your users don't use that broken client
>>> anymore - not a very good scenario if you ask me.
>
>> But, more to the point, why are we discussing methods to solve a
>> problem
>> which has already been solved?
>
> Forgive my ignorance, but how do you solve the problem of bad clients
> (mis)communicating with a server if you cant get a 'id' of the client
> in
> order to deny it?
You don't. The point we're trying to make is that a client is judged
"bad" by its *behavior*, not some version number attached to it. We've
been talking about all the different ways to detect/prevent bad
behaviors... e.g. not attaching an issue number to a commit message.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Request: make the user agent string a define
Posted by "Steven H @ orcon" <sm...@orcon.net.nz>.
Max Bowsher wrote:
> SteveKing wrote:
>> During the time in which you wait for a new server release, you
>> can then only pray that all your users don't use that broken client
>> anymore - not a very good scenario if you ask me.
> But, more to the point, why are we discussing methods to solve a problem
> which has already been solved?
Forgive my ignorance, but how do you solve the problem of bad clients
(mis)communicating with a server if you cant get a 'id' of the client in
order to deny it?
---------------------------------------------------------------------------
Steven Higgan - 3rd Year B.I.T. Otago Polytechnic, Dunedin New Zealand
.net geek
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> So, you discover that a client has a bug and the server doesn't reject
> the commit. Now what do you do? The only thing you can do is wait for a
> new release of the server, but that will take some time because such a
> bug is not urgent enough (after all, it's the client who sends garbage
> data). During the time in which you wait for a new server release, you
> can then only pray that all your users don't use that broken client
> anymore - not a very good scenario if you ask me.
Or, you can implement appropriate checking in the pre-commit script.
But, more to the point, why are we discussing methods to solve a problem
which has already been solved?
> But let's kick aside the why and what for that feature is needed and
> what would be different and in your opinion much better solutions.
> Let's just accept that users want such a feature, even if you don't
> understand why they want it.
We are having a philosophical disconnect here.
First, if we don't understand why a feature is wanted, how can we do a good
job of designing it?
Second, when better solutions have been raised for every use case so far
mentioned, why would we want to implement the feature?
> So would it be possible to make that user-agent string so that a client
> can change it? I'd really hate it if I had to patch Subversion too - I
> already had to do it with apr-iconv...
So would I.
But would you even *want* to, when we've provided better ways to handle the
problems you've cited as reasons for wanting the feature?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Erik Huelsmann wrote:
[snip]
>>Just think of a client which has a bug and doesn't properly UTF8 encode
>>and/or check the lineendings before calling that function. Then you'll
>>end up with unwanted data in the repository which other clients don't
>>understand anymore.
>
> It's a bug in the server if it accepts data which should be utf-8
> encoded, but is not. The docstring tells you the libraries rely on the
> client to do the UTF-8 encoding. It's up to the server to check. Next
> to that, it's Subversion protocol documentation.
At the time TSVN had that bug, the server didn't reject the commits from
it. So at that time, the Subversion server had that bug (don't know if
it's still there, haven't tested).
So, you discover that a client has a bug and the server doesn't reject
the commit. Now what do you do? The only thing you can do is wait for a
new release of the server, but that will take some time because such a
bug is not urgent enough (after all, it's the client who sends garbage
data). During the time in which you wait for a new server release, you
can then only pray that all your users don't use that broken client
anymore - not a very good scenario if you ask me.
But let's kick aside the why and what for that feature is needed and
what would be different and in your opinion much better solutions.
Let's just accept that users want such a feature, even if you don't
understand why they want it.
So would it be possible to make that user-agent string so that a client
can change it? I'd really hate it if I had to patch Subversion too - I
already had to do it with apr-iconv...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi!
On Sat, 08 Jan 2005 20:43:18 +0100, SteveKing <st...@gmx.ch> wrote:
> Max Bowsher wrote:
> > SteveKing wrote:
> >> Ok, that's your opinion. Other users disagree with that, and I do too.
> >> If I were responsible for a Subversion server and I knew that there are
> >> client versions around which have either security bugs or other bugs
> >> which could harm the server, I'd like to be able to reject those
> >> clients. Sure, you could mail all the users and tell them to upgrade
> >> their clients, but you'll discover soon that most of them just don't do
> >> it.
> >
> > How can a bug in the client harm the server?
>
> Very simple. Just have a look at all the svn_client_* functions. Example:
> svn_client_propset()
> "If propname is an svn-controlled property (i.e. prefixed with
> SVN_PROP_PREFIX), then the caller is responsible for ensuring that the
> value is UTF8-encoded and uses LF line-endings."
>
> Just think of a client which has a bug and doesn't properly UTF8 encode
> and/or check the lineendings before calling that function. Then you'll
> end up with unwanted data in the repository which other clients don't
> understand anymore.
It's a bug in the server if it accepts data which should be utf-8
encoded, but is not. The docstring tells you the libraries rely on the
client to do the UTF-8 encoding. It's up to the server to check. Next
to that, it's Subversion protocol documentation.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Shawn Harrison <ha...@tbc.net>.
Max Bowsher wrote [01/09/05 5:09 AM]:
> I don't agree with that. I think the role of a developer is to create a
> well-designed useful and maintainable system.
> Sometimes, that includes questioning the users suggested design for
> achieving something, and maybe doing things a better way instead.
> ...
> But it's exactly the kind of piecemeal undesigned feature which we try
> extremely hard to avoid.
This, to my mind, is a nutshell explanation of why SVN is so good:
because it is well-designed. Keep up the good work.
I would also echo the statement earlier, "TSVN is fantastic." Yes! A
wonderful tool. Even the CEO of the publishing company I work for uses
it frequently with no hiccups. TSVN does an amazing job of making a
rather sophisticated software system transparently easy to use for
people who have no technical knowledge of computers at all.
Shawn Harrison
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 10, 2005, at 1:34 PM, Toby Johnson wrote:
> An option which hasn't gotten much discussion is the ability to pass
> an environment variable on to the hook scripts. This to me
Following this discussion, the underlying desire appears to me as: in
certain installations where a more structured system has been built
upon Subversion, the owners/developers of these installations want a
side-channel so they can communicate between their clients and their
code on the server (in hook scripts).
Toby's request about passing an environment variable is a
implementation-minded request for such a side-channel.
Would such a built-in-side-communication-channel be generally
worthwhile? Or should those building structured systems on top of
Subversion be building their own communication channels for their own
purposes? I think in this case, the channels would be made at the time
of every Subversion client command that contacts the server and so the
requesters want to piggy-back on the channel that is already in place
(and take advantage of all details of which server to contact, user
authentication, etc that Subversion already handles).
At this time, I don't see that such a need for a side channel has been
shown. Not for the examples suggested upon this thread anyway.
For Toby's purposes, he could just have his client programs (maybe via
a wrapper if TSVN doesn't support it directly) send some version info
to some alternate server daemon that would respond whether that version
is acceptable or respond that it isn't up-to-date so that the client
software will inform the user that he or she needs to update his or her
client "because Toby said so." :-) That server daemon could also log
that client version string from each request for the statistics that he
desires.
The TSVN project could add appropriate features and hooks so as to make
this a nice TSVN feature.
There's no reason that all of this needs to be built into the
Subversion version control software which refrains from feature bloat.
:-)
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: client-to-server environment variables (was: make the
user agent string a define)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, January 10, 2005 11:35 PM +0000 Max Bowsher <ma...@ukf.net>
wrote:
> Sure, I said environment variables would be a suitable way to pass
> information that the server happens to have available to hook scripts.
>
> But now you are talking about some kind of generic mechanism for
> marshalling arbitrary key/value pairs from the client to the hook scripts?
Actually, environment variables are not passed through to the hook scripts
(see svn_io_run_cmd with the NULL argument for env). Greg Hudson and I had
a discussion about that recently on here. The precedent in httpd is not to
pass them, however it's semi-reasonable to expect that for SSH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: client-to-server environment variables
Posted by Toby Johnson <to...@etjohnson.us>.
Max Bowsher wrote:
> But now you are talking about some kind of generic mechanism for
> marshalling arbitrary key/value pairs from the client to the hook
> scripts?
>
> I speak only for myself, not the Subversion developers in general, but
> my opinion is that this is a horrible idea.
> It destroys the whole principle of "Subversion clients are compatible
> with Subversion servers", and makes you use a client which happens to
> support whatever random things the hook scripts have been built to use.
I think you are brushing aside closed shops that wish to build
applications on top of Subversion. The ability to connect to any client
which a user happens to be using is not a consideration in these cases;
in fact, there are many businesses which would want to specifically
avoid this scenario. They will deploy a particular client (such as TSVN)
and expect that everyone who accesses the repository uses that client.
However, I only made this suggestion because you seemed to balk at the
idea of passing a client string to the server in any form, because some
dastardly admin may use it for evil purposes. Your comment "I agree
[environment variables] would be a good way to pass arbitrary
information to hook scripts" seemed to imply that a general mechanism
for this was more favorable, but I've obviously misinterpreted this.
So, let's take yet another step back. The problem is that a lot of users
want to know what sorts of clients are connecting to their repository.
You agree that environment variables may be a suitable mechanism for
passing this information. So the question that remains is, how does the
server get this information in the first place? By another (or perhaps
the same) environment variable set by the client?
> If you are finding the built in Windows scripting tools deficient (and
> let's face it, they are), then both Python and Perl are well-packaged
> for Windows.
Yes, I'm aware of and have used both Python and Perl for hook scripts,
but again you're missing the point here: Python and Perl are not very
common on Windows servers. Even if you can convince your sysadmin to
install them, programming a hook script using either of these is not
exactly trivial, especially given the (lack of) familiarity of typical
Windows programmers with these tools. It's the difference between making
something possible and making it easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: client-to-server environment variables (was: make the user agent string a define)
Posted by Max Bowsher <ma...@ukf.net>.
Toby Johnson wrote:
> Max Bowsher wrote:
>
>> I am the one who first mentioned the environment variable mechanism in
>> this discussion. I agree it would be a good way to pass arbitrary
>> information to hook scripts.
>
> OK, can we concentrate on this then? I think everyone involved agrees
> that implementing a very generic mechanism to make this possible is both
> desirable and possible while not breaking older clients. If Steve/TSVN
> wants to implement some other mechanism whereby users can send client
> version or other info, that would be up to the TSVN project and the
> Subversion client wouldn't need to do anything special with particular
> variables.
Ummm, what?
Sure, I said environment variables would be a suitable way to pass
information that the server happens to have available to hook scripts.
But now you are talking about some kind of generic mechanism for marshalling
arbitrary key/value pairs from the client to the hook scripts?
I speak only for myself, not the Subversion developers in general, but my
opinion is that this is a horrible idea.
It destroys the whole principle of "Subversion clients are compatible with
Subversion servers", and makes you use a client which happens to support
whatever random things the hook scripts have been built to use.
> IMO, this would also make hook scripts much easier for Windows admins.
> Environment variables are much easier to deal with from a batch script
> than having to use either the SVN libs or svnlook to examine author,
> log, etc.
If you are finding the built in Windows scripting tools deficient (and let's
face it, they are), then both Python and Perl are well-packaged for Windows.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Request: client-to-server environment variables (was: make the user
agent string a define)
Posted by Toby Johnson <to...@etjohnson.us>.
Max Bowsher wrote:
> I am the one who first mentioned the environment variable mechanism in
> this discussion. I agree it would be a good way to pass arbitrary
> information to hook scripts.
OK, can we concentrate on this then? I think everyone involved agrees
that implementing a very generic mechanism to make this possible is both
desirable and possible while not breaking older clients. If Steve/TSVN
wants to implement some other mechanism whereby users can send client
version or other info, that would be up to the TSVN project and the
Subversion client wouldn't need to do anything special with particular
variables.
IMO, this would also make hook scripts much easier for Windows admins.
Environment variables are much easier to deal with from a batch script
than having to use either the SVN libs or svnlook to examine author,
log, etc.
For security reasons (i.e. preventing users from being able to modify
$PATH), all environment variables passed in such a manner would need to
be prefixed in the ra layer with "SVN_" or something similar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
Toby Johnson wrote:
> I'm the one who requested this on the TSVN list, and didn't realize this
> entire discussion was happening over here!
>
> Max Bowsher wrote:
>
>> I've explained already why rejecting versions is a poor approach due
>> to virtual certainty of false positives, and unnecessary encumberance
>> on users.
>
> You are looking at this from the perspective of running a repository
> with many disparate users. In my shop, almost all users connect via
> TSVN, and I want to be able to force them to upgrade to new clients
> within a reasonable timeframe. This is not intended as an airtight
> security feature. It is meant to get relatively non-technical people to
> keep their machines updated, in order to give me a (somewhat) more
> homogenous environment of users to deal with.
Seems to me that the ideal way to deal with this is to circulate a rule in
your shop that "If you want support from me you must be running version X or
later."
If a user is happy with the software they have, not experiencing problems,
and in the middle of a task, why should they have to upgrade because of
someone else's whim, if their non-upgrading harms no-one?
> However, I think Steve wishes he never gave this as an example because
> this use-case has dominated the conversation. I know and understand why
> the approach I want to take may not be technically the best solution or
> it may not prevent a determined user from circumventing it, but that's
> not the point. This capability would (as you mention) be useful for
> other purposes such as statistics-gathering.
>
> An option which hasn't gotten much discussion is the ability to pass an
> environment variable on to the hook scripts. This to me seems like the
> best way to get arbitrary info from the client to the server without
> cluttering up the repository. If someone wants to gather statistics on
> their clients, they could easily write this to a logfile. I could use it
> for the reasons I want, regardless of whether you think my reasons or my
> approach are the best.
I am the one who first mentioned the environment variable mechanism in this
discussion. I agree it would be a good way to pass arbitrary information to
hook scripts.
I don't agree that passing the client version to the hook script is
necessary or desirable.
>> However, the whole 'rejecting clients based on version' argument has
>> opened my eyes to the potential for abusing the feature, making me
>> feel rather disturbed about the whole idea.
>
> This argument is pretty empty. Every single feature in Subversion could
> be "abused" this way. I could set up my repository so that pre-commit
> rejects commits on even-numbered hours of the day. I'm sure this would
> be termed "abuse" by you, but does this mean that svn:date is a bad idea
> and should not have been implemented?
Forget svn:date - you could take the time from the server's clock.
This is a frivolous synthetic example in any case - to so has no possible
point whatsoever.
This case is different: It is a non-trivial new feature which has much
potential for abuse, and very little for positive use.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Toby Johnson <to...@etjohnson.us>.
I'm the one who requested this on the TSVN list, and didn't realize this
entire discussion was happening over here!
Max Bowsher wrote:
> I've explained already why rejecting versions is a poor approach due
> to virtual certainty of false positives, and unnecessary encumberance
> on users.
You are looking at this from the perspective of running a repository
with many disparate users. In my shop, almost all users connect via
TSVN, and I want to be able to force them to upgrade to new clients
within a reasonable timeframe. This is not intended as an airtight
security feature. It is meant to get relatively non-technical people to
keep their machines updated, in order to give me a (somewhat) more
homogenous environment of users to deal with.
However, I think Steve wishes he never gave this as an example because
this use-case has dominated the conversation. I know and understand why
the approach I want to take may not be technically the best solution or
it may not prevent a determined user from circumventing it, but that's
not the point. This capability would (as you mention) be useful for
other purposes such as statistics-gathering.
An option which hasn't gotten much discussion is the ability to pass an
environment variable on to the hook scripts. This to me seems like the
best way to get arbitrary info from the client to the server without
cluttering up the repository. If someone wants to gather statistics on
their clients, they could easily write this to a logfile. I could use it
for the reasons I want, regardless of whether you think my reasons or my
approach are the best.
> However, the whole 'rejecting clients based on version' argument has
> opened my eyes to the potential for abusing the feature, making me
> feel rather disturbed about the whole idea.
This argument is pretty empty. Every single feature in Subversion could
be "abused" this way. I could set up my repository so that pre-commit
rejects commits on even-numbered hours of the day. I'm sure this would
be termed "abuse" by you, but does this mean that svn:date is a bad idea
and should not have been implemented?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Ben Collins-Sussman wrote:
>
>>> Can we just say that many people would like to know (for whatever
>>> reasons they have, wheter you agree with them or not) with which
>>> client users connect to the repository and leave it at that?
>>
>> The truth is, that's just not the way the Subversion project works.
>> Perhaps it's a philosophical difference between the Subversion and TSVN
>> projects.
>>
>> My impression is that TSVN has a pragmatic style of development: "if
>> lots of users ask for it, then it must be something useful, and
>> therefore it must be something Good and worth doing."
>
> It's not "... then it must be something useful" but "then it's a feature
> we should offer, whether we think it's useful or not". It's not up to us
> devs to decide what users need but to do what they want (of cource, it
> it doesn't break something else or would create some other risk).
I don't agree with that. I think the role of a developer is to create a
well-designed useful and maintainable system.
Sometimes, that includes questioning the users suggested design for
achieving something, and maybe doing things a better way instead.
>> But in the Subversion project we don't believe that. If we hear many
>> requests for something, we still want to debate the merits of the idea,
>> offer counter-solutions, and generally consider the impact of such a
>> feature on the software overall. (For example: we won't implement the
>> $Log$ keyword, even though people ask about it all the time.)
>
> And that's reasonable. You explained why that $Log$ keyword would be
> dangerous, that's fair enough.
> But as for changing e.g. the user-agent string, that's not dangerous at
> all, is easy to do (I guess it would take a Subversion def 5 minutes to
> change that into a define) and would definitely _not_ break anything else.
But it's exactly the kind of piecemeal undesigned feature which we try
extremely hard to avoid.
The reason for the existance the of the user-agent header is purely because
it was inherited from HTTP. It's not supposed to have any real relevance to
Subversion.
Besides, suppose we were to change the user-agent string. What then, do we
do about svn:// access?
>> So your request above doesn't make a lot of sense to us: in our minds,
>> popularity alone isn't a strong argument for a new feature. We refuse
>> to say, "well, people have their reasons" and then forget about it.
>> That's why you see Max and Erik trying to understand *why* users are
>> asking for the feature.
>
> I've explained the 'why', at least I think I did. It's just that I'm
> getting tired of explaining things over and over again. For example, to
> write a letter, I'd like to use a program with certain features. Even if
> I know that I could use e.g. notepad or even a simple pencil for that
> task.
> The same applies to those other solutions people here offered: write a
> hook script that checks for that specific bad data and reject that
> instead of a specific client: that would mean every time you discover
> such a bug you have to write a completely new hook script. If I could
> reject that certain client, I could use the same hook script and just
> adjust the client version strings I'd like to reject.
I've explained already why rejecting versions is a poor approach due to
virtual certainty of false positives, and unnecessary encumberance on users.
Regarding the work... this entire broken data problem has a reasonable
chance of *never* happening again. And, if it does, then the community can
assemble a hook script and share it.
>> I really hate the fact that we so often end up getting into stubborn
>> arguments with you, Steve. We certainly have no ill will towards you,
>> no matter how it may appear. (I think TSVN is fantastic, and I love the
>> work you do!) I'd love to see more and more collaboration between
>> Subversion and TSVN. Don't let these debates frustrate you. :-)
>
> Ok, so I'll try again explaining why I'd like the feature (put aside
> _how_ it's done, I just want to check the client and version on the
> server):
>
> - rejecting clients based on their version number.
> - rejecting because a specific client has a bug
> - forcing users to upgrade (_very_ useful in companies. That way you
> don't have to go to each developers workstation and tell them again and
> again to update). Sure, old clients would work too, but if you have to
> support even very, very old versions of clients which you know have a
> lot of bugs which are fixed in newer versions, you'd like to force your
> users to update the clients.
> - rejecting 'too new' clients before the admin had the chance to test
> those with his own server.
>
> - building statistics (that's why _I_ want that feature)
> - with which clients do my users connect to the repository?
> - which is the most used client program?
I actually find the statistics argument reasonably convincing - but I'd want
a solution which worked for ra_svn (and ra_local?) too.
However, the whole 'rejecting clients based on version' argument has opened
my eyes to the potential for abusing the feature, making me feel rather
disturbed about the whole idea.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
>> Can we just say that many people would like to know (for whatever
>> reasons they have, wheter you agree with them or not) with which
>> client users connect to the repository and leave it at that?
>
> The truth is, that's just not the way the Subversion project works.
> Perhaps it's a philosophical difference between the Subversion and TSVN
> projects.
>
> My impression is that TSVN has a pragmatic style of development: "if
> lots of users ask for it, then it must be something useful, and
> therefore it must be something Good and worth doing."
It's not "... then it must be something useful" but "then it's a feature
we should offer, whether we think it's useful or not". It's not up to us
devs to decide what users need but to do what they want (of cource, it
it doesn't break something else or would create some other risk).
> But in the Subversion project we don't believe that. If we hear many
> requests for something, we still want to debate the merits of the idea,
> offer counter-solutions, and generally consider the impact of such a
> feature on the software overall. (For example: we won't implement the
> $Log$ keyword, even though people ask about it all the time.)
And that's reasonable. You explained why that $Log$ keyword would be
dangerous, that's fair enough.
But as for changing e.g. the user-agent string, that's not dangerous at
all, is easy to do (I guess it would take a Subversion def 5 minutes to
change that into a define) and would definitely _not_ break anything else.
> So your request above doesn't make a lot of sense to us: in our minds,
> popularity alone isn't a strong argument for a new feature. We refuse
> to say, "well, people have their reasons" and then forget about it.
> That's why you see Max and Erik trying to understand *why* users are
> asking for the feature.
I've explained the 'why', at least I think I did. It's just that I'm
getting tired of explaining things over and over again. For example, to
write a letter, I'd like to use a program with certain features. Even if
I know that I could use e.g. notepad or even a simple pencil for that task.
The same applies to those other solutions people here offered: write a
hook script that checks for that specific bad data and reject that
instead of a specific client: that would mean every time you discover
such a bug you have to write a completely new hook script. If I could
reject that certain client, I could use the same hook script and just
adjust the client version strings I'd like to reject.
> I really hate the fact that we so often end up getting into stubborn
> arguments with you, Steve. We certainly have no ill will towards you,
> no matter how it may appear. (I think TSVN is fantastic, and I love the
> work you do!) I'd love to see more and more collaboration between
> Subversion and TSVN. Don't let these debates frustrate you. :-)
Ok, so I'll try again explaining why I'd like the feature (put aside
_how_ it's done, I just want to check the client and version on the server):
- rejecting clients based on their version number.
- rejecting because a specific client has a bug
- forcing users to upgrade (_very_ useful in companies. That way you
don't have to go to each developers workstation and tell them again and
again to update). Sure, old clients would work too, but if you have to
support even very, very old versions of clients which you know have a
lot of bugs which are fixed in newer versions, you'd like to force your
users to update the clients.
- rejecting 'too new' clients before the admin had the chance to test
those with his own server.
- building statistics (that's why _I_ want that feature)
- with which clients do my users connect to the repository?
- which is the most used client program?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 8, 2005, at 4:02 PM, SteveKing wrote:
> Can we just say that many people would like to know (for whatever
> reasons they have, wheter you agree with them or not) with which
> client users connect to the repository and leave it at that?
>
The truth is, that's just not the way the Subversion project works.
Perhaps it's a philosophical difference between the Subversion and TSVN
projects.
My impression is that TSVN has a pragmatic style of development: "if
lots of users ask for it, then it must be something useful, and
therefore it must be something Good and worth doing."
But in the Subversion project we don't believe that. If we hear many
requests for something, we still want to debate the merits of the idea,
offer counter-solutions, and generally consider the impact of such a
feature on the software overall. (For example: we won't implement the
$Log$ keyword, even though people ask about it all the time.)
So your request above doesn't make a lot of sense to us: in our minds,
popularity alone isn't a strong argument for a new feature. We refuse
to say, "well, people have their reasons" and then forget about it.
That's why you see Max and Erik trying to understand *why* users are
asking for the feature.
I really hate the fact that we so often end up getting into stubborn
arguments with you, Steve. We certainly have no ill will towards you,
no matter how it may appear. (I think TSVN is fantastic, and I love
the work you do!) I'd love to see more and more collaboration between
Subversion and TSVN. Don't let these debates frustrate you. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Can we just say that many people would like to know (for whatever
> reasons they have, wheter you agree with them or not) with which client
> users connect to the repository and leave it at that?
Well, we could leave it at the current situation, which is that neither side
of the discussion understands the ideas held by the other side, but I doubt
that would be satisfactory to anyone.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Can we just say that many people would like to know (for whatever
reasons they have, wheter you agree with them or not) with which client
users connect to the repository and leave it at that?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Max Bowsher wrote:
>> SteveKing wrote:
>>> Ok, that's your opinion. Other users disagree with that, and I do too.
>>> If I were responsible for a Subversion server and I knew that there are
>>> client versions around which have either security bugs or other bugs
>>> which could harm the server, I'd like to be able to reject those
>>> clients. Sure, you could mail all the users and tell them to upgrade
>>> their clients, but you'll discover soon that most of them just don't do
>>> it.
>>
>> How can a bug in the client harm the server?
>
> Very simple. Just have a look at all the svn_client_* functions. Example:
> svn_client_propset()
> "If propname is an svn-controlled property (i.e. prefixed with
> SVN_PROP_PREFIX), then the caller is responsible for ensuring that the
> value is UTF8-encoded and uses LF line-endings."
>
> Just think of a client which has a bug and doesn't properly UTF8 encode
> and/or check the lineendings before calling that function. Then you'll
> end up with unwanted data in the repository which other clients don't
> understand anymore.
>
> In the very beginning of TSVN, there was a similar bug (way before 1.0,
> so not a risk anymore).
>
> Me as the one responsible for a server would like to make sure that
> users don't use that specific client anymore and reject any commits
> coming from them.
A better response would be to build appropriate verification into the
server.
>> And even if it could, pre-commit would be rather too late to check.
>
> It would be late, but not too late. And once users see the error message
> from the pre-commit hook (maybe with a nice "please use a client >
> version X" message) users would have to update and the problem would be
> solved.
OK, for this *very specific* kind of problem, pre-commit could help - *but*
you don't need to try do some kind of version matching, which might lock out
valid clients - you can simply have the pre-commit verify that the data is
UTF8 and LF-terminated before allowing the commit.
>> Besides I could be using an old client with a backported security fix.
>
> But such a client would then have a different version number assigned to
> it.
I am referring to backports by other entities than the Subversion project
itself, i.e. Linux/BSD distros, etc.
In such a case the client will *NOT* have a different version number, and
version tests will be unreliable.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Max Bowsher wrote:
> SteveKing wrote:
>> Ok, that's your opinion. Other users disagree with that, and I do too.
>> If I were responsible for a Subversion server and I knew that there are
>> client versions around which have either security bugs or other bugs
>> which could harm the server, I'd like to be able to reject those
>> clients. Sure, you could mail all the users and tell them to upgrade
>> their clients, but you'll discover soon that most of them just don't do
>> it.
>
> How can a bug in the client harm the server?
Very simple. Just have a look at all the svn_client_* functions. Example:
svn_client_propset()
"If propname is an svn-controlled property (i.e. prefixed with
SVN_PROP_PREFIX), then the caller is responsible for ensuring that the
value is UTF8-encoded and uses LF line-endings."
Just think of a client which has a bug and doesn't properly UTF8 encode
and/or check the lineendings before calling that function. Then you'll
end up with unwanted data in the repository which other clients don't
understand anymore.
In the very beginning of TSVN, there was a similar bug (way before 1.0,
so not a risk anymore).
Me as the one responsible for a server would like to make sure that
users don't use that specific client anymore and reject any commits
coming from them.
> And even if it could, pre-commit would be rather too late to check.
It would be late, but not too late. And once users see the error message
from the pre-commit hook (maybe with a nice "please use a client >
version X" message) users would have to update and the problem would be
solved.
> Besides I could be using an old client with a backported security fix.
But such a client would then have a different version number assigned to it.
>>> I still think that the SVN libraries are the user-agent, not whatever
>>> happens to be guiding their actions.
>>
>> I don't see the point in a user-agent string which always tells
>> "SVN/xxx" - every commit to a Subversion repository has to be some kind
>> of svn client. Imagine that all webbrowsers would have the same
>> user-agent string "Browser/XXX" - that would be pretty useless.
>
> I guess "SVN/x.y.z (some additional settable string)" would be OK.
Sure. That's what clients would probably do anyway (include the version
number of the subversion libs they're linked to).
>> But it can only go into a log file if the repository is hosted by
>> Apache. It can't go there for svn://, svn+ssh//, file:/// - because
>> those don't get a user-agent string.
>>
>>> To ruthlessly over-extend your metaphor, that would be like the
>>> webserver appending the user-agent info in coded footers on the .html
>>> files being served.
>>
>>
>> Not really. Webpages are shown to the user. A revprop usually isn't.
>
> I was envisaging the webserver not showing the footers to clients.
> The point is, that transient data doesn't belong bound to permanent data.
Ok, then we need another way a client can pass data with a commit to the
server so the server can check that data in a pre-commit hook.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Max Bowsher wrote:
> [snip]
>>> It's not to forbid a reliable client. It's to forcing users to update
>>> their clients (e.g. in case of a security bug in older versions or in
>>> this case to enforce a client which has certain features so users don't
>>> forget to enter an issue number, write a log message with a minimum log
>>> message size, ...)
>>
>> Personally, I don't think the server has the right to dictate versions
>> to the client.
>> Only to agree or refuse to the commit the client proposes.
>
> Ok, that's your opinion. Other users disagree with that, and I do too.
> If I were responsible for a Subversion server and I knew that there are
> client versions around which have either security bugs or other bugs
> which could harm the server, I'd like to be able to reject those
> clients. Sure, you could mail all the users and tell them to upgrade
> their clients, but you'll discover soon that most of them just don't do
> it.
How can a bug in the client harm the server?
And even if it could, pre-commit would be rather too late to check.
Besides I could be using an old client with a backported security fix.
>> Why not have the pre-commit check for the suitability of the log message?
>> If enter a valid log message in a client which doesn't force me to enter
>> a valid log message, the commit should still succeed.
>
> Because then the users complain about their commit being rejected. If
> the client can check/help with that before you even start the commit you
> can save time.
But the commit would only be rejected if they weren't using a helpful
client.
>> I still think that the SVN libraries are the user-agent, not whatever
>> happens to be guiding their actions.
>
> I don't see the point in a user-agent string which always tells
> "SVN/xxx" - every commit to a Subversion repository has to be some kind
> of svn client. Imagine that all webbrowsers would have the same
> user-agent string "Browser/XXX" - that would be pretty useless.
I guess "SVN/x.y.z (some additional settable string)" would be OK.
>>>> Logging the useragent of every commit into a revprop?
>>>>
>>>> My initial reaction is "yuck!".
>>>>
>>>> What real use could this data be put to?
>>>
>>>
>>> Think about a statistics page generated of a repository. Or do you think
>>> that all those web statistics which show the browser (type and version)
>>> with which the webpage was accessed are completely useless too?
>>> Sure, it's not something that's very important, but surely 'nice to
>>> have'.
>>
>> Yes, but that sort of statistics goes in a log file.
>
> But it can only go into a log file if the repository is hosted by
> Apache. It can't go there for svn://, svn+ssh//, file:/// - because
> those don't get a user-agent string.
>
>> To ruthlessly over-extend your metaphor, that would be like the
>> webserver appending the user-agent info in coded footers on the .html
>> files being served.
>
> Not really. Webpages are shown to the user. A revprop usually isn't.
I was envisaging the webserver not showing the footers to clients.
The point is, that transient data doesn't belong bound to permanent data.
>>> Also, revprops can be checked in a pre-commit hook.
>>
>> So can environment variables or command line parameters.
>
> That I don't understand. How can an environment variable or a command
> line parameter on the client side be checked by a pre-commit hook on the
> server?
It can't. But AFAICS, your suggestion of a revprop was just as a vehicle to
expose the information to pre-commit.
The server could equally well pass the information to the pre-commit hook as
an environment variable or command line parameter.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Max Bowsher wrote:
[snip]
>> It's not to forbid a reliable client. It's to forcing users to update
>> their clients (e.g. in case of a security bug in older versions or in
>> this case to enforce a client which has certain features so users don't
>> forget to enter an issue number, write a log message with a minimum log
>> message size, ...)
>
> Personally, I don't think the server has the right to dictate versions
> to the client.
> Only to agree or refuse to the commit the client proposes.
Ok, that's your opinion. Other users disagree with that, and I do too.
If I were responsible for a Subversion server and I knew that there are
client versions around which have either security bugs or other bugs
which could harm the server, I'd like to be able to reject those
clients. Sure, you could mail all the users and tell them to upgrade
their clients, but you'll discover soon that most of them just don't do it.
> Why not have the pre-commit check for the suitability of the log message?
> If enter a valid log message in a client which doesn't force me to enter
> a valid log message, the commit should still succeed.
Because then the users complain about their commit being rejected. If
the client can check/help with that before you even start the commit you
can save time.
> I still think that the SVN libraries are the user-agent, not whatever
> happens to be guiding their actions.
I don't see the point in a user-agent string which always tells
"SVN/xxx" - every commit to a Subversion repository has to be some kind
of svn client. Imagine that all webbrowsers would have the same
user-agent string "Browser/XXX" - that would be pretty useless.
>>> Logging the useragent of every commit into a revprop?
>>>
>>> My initial reaction is "yuck!".
>>>
>>> What real use could this data be put to?
>>
>>
>> Think about a statistics page generated of a repository. Or do you think
>> that all those web statistics which show the browser (type and version)
>> with which the webpage was accessed are completely useless too?
>> Sure, it's not something that's very important, but surely 'nice to
>> have'.
>
> Yes, but that sort of statistics goes in a log file.
But it can only go into a log file if the repository is hosted by
Apache. It can't go there for svn://, svn+ssh//, file:/// - because
those don't get a user-agent string.
> To ruthlessly over-extend your metaphor, that would be like the
> webserver appending the user-agent info in coded footers on the .html
> files being served.
Not really. Webpages are shown to the user. A revprop usually isn't.
>> Also, revprops can be checked in a pre-commit hook.
>
> So can environment variables or command line parameters.
That I don't understand. How can an environment variable or a command
line parameter on the client side be checked by a pre-commit hook on the
server?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Max Bowsher wrote:
>> SteveKing wrote:
>>> A feature which is requested often on the TSVN mailing list is the
>>> ability to check the client version in a pre-commit hook.
>>> (the latest request was because they wanted to reject commits from TSVN
>>> clients which don't have the bugtraq features implemented yet)
>>
>> For the non TSVN users here, could you explain what these features are?
>
> Sure:
> TSVN introduced some properties which it uses to make it easier for
> users to enter issue numbers into a log message.
> The document describing this is located here:
> http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
>
> Other properties TSVN introduced and which users/admins make want to
> enforce a minimum TSVN version numbers are documented here:
> http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch04s09.html
>
>> Perhaps because I don't understand that, I can't see any reason to
>> forbid a client which can talk a compatible protocol from communicating
>> with a Subversion server.
>
> It's not to forbid a reliable client. It's to forcing users to update
> their clients (e.g. in case of a security bug in older versions or in
> this case to enforce a client which has certain features so users don't
> forget to enter an issue number, write a log message with a minimum log
> message size, ...)
Personally, I don't think the server has the right to dictate versions to
the client.
Only to agree or refuse to the commit the client proposes.
Why not have the pre-commit check for the suitability of the log message?
If enter a valid log message in a client which doesn't force me to enter a
valid log message, the commit should still succeed.
>>> I've searched the mailing lists and found that this is already possible
>>> if the repository is hosted on an Apache server.
>>> (http://svn.haxx.se/dev/archive-2003-05/1680.shtml)
>>>
>>> Then I looked at the source where that agent string is set/sent:
>>> subversion/libsvn_ra_dav/session.c, line 659,660 (1.1.2 tag)
>>> ne_set_useragent(sess, "SVN/" SVN_VERSION);
>>> ne_set_useragent(sess2, "SVN/" SVN_VERSION);
>>>
>>> As it is now, another client can't change that string to something else
>>> (e.g. "TSVN/1.1.2"), so I'd like to request that this is changed into a
>>> define (which of course defaults to "SVN/"SVN_VERSION) but can be
>>> changed by a client when compiling/linking to the Subversion libs.
>>
>>
>> I don't think that a define can do that.
>
> Why not? You can write something like
> #ifndef SVN_AGENT_STRING
> #define SVN_AGENT_STRING "SVN/"SVN_VERSION
> #endif
> and then use SVN_AGENT_STRING in those two lines mentioned above.
> A client could then compile the Subversion libs with SVN_AGENT_STRING
> set to something else.
I read your previous email as speaking about a client which is compiled and
linked to pre-existing Subversion libs.
I still think that the SVN libraries are the user-agent, not whatever
happens to be guiding their actions.
>>> Even better would be if Subversion would allow to set revprops with
>>> every command that affects the repository. That way, a new revprop (e.g.
>>> svn:user-agent) could be written every time. This would also have the
>>> advantage that you could later check each revision and find out with
>>> which client is was made. And of course it wouldn't be restricted to
>>> Apache based repositories.
>>
>> Logging the useragent of every commit into a revprop?
>>
>> My initial reaction is "yuck!".
>>
>> What real use could this data be put to?
>
> Think about a statistics page generated of a repository. Or do you think
> that all those web statistics which show the browser (type and version)
> with which the webpage was accessed are completely useless too?
> Sure, it's not something that's very important, but surely 'nice to have'.
Yes, but that sort of statistics goes in a log file.
To ruthlessly over-extend your metaphor, that would be like the webserver
appending the user-agent info in coded footers on the .html files being
served.
> Also, revprops can be checked in a pre-commit hook.
So can environment variables or command line parameters.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Max Bowsher wrote:
> SteveKing wrote:
>> A feature which is requested often on the TSVN mailing list is the
>> ability to check the client version in a pre-commit hook.
>> (the latest request was because they wanted to reject commits from TSVN
>> clients which don't have the bugtraq features implemented yet)
>
> For the non TSVN users here, could you explain what these features are?
Sure:
TSVN introduced some properties which it uses to make it easier for
users to enter issue numbers into a log message.
The document describing this is located here:
http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
Other properties TSVN introduced and which users/admins make want to
enforce a minimum TSVN version numbers are documented here:
http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch04s09.html
> Perhaps because I don't understand that, I can't see any reason to
> forbid a client which can talk a compatible protocol from communicating
> with a Subversion server.
It's not to forbid a reliable client. It's to forcing users to update
their clients (e.g. in case of a security bug in older versions or in
this case to enforce a client which has certain features so users don't
forget to enter an issue number, write a log message with a minimum log
message size, ...)
>> I've searched the mailing lists and found that this is already possible
>> if the repository is hosted on an Apache server.
>> (http://svn.haxx.se/dev/archive-2003-05/1680.shtml)
>>
>> Then I looked at the source where that agent string is set/sent:
>> subversion/libsvn_ra_dav/session.c, line 659,660 (1.1.2 tag)
>> ne_set_useragent(sess, "SVN/" SVN_VERSION);
>> ne_set_useragent(sess2, "SVN/" SVN_VERSION);
>>
>> As it is now, another client can't change that string to something else
>> (e.g. "TSVN/1.1.2"), so I'd like to request that this is changed into a
>> define (which of course defaults to "SVN/"SVN_VERSION) but can be
>> changed by a client when compiling/linking to the Subversion libs.
>
>
> I don't think that a define can do that.
Why not? You can write something like
#ifndef SVN_AGENT_STRING
#define SVN_AGENT_STRING "SVN/"SVN_VERSION
#endif
and then use SVN_AGENT_STRING in those two lines mentioned above.
A client could then compile the Subversion libs with SVN_AGENT_STRING
set to something else.
>> Even better would be if Subversion would allow to set revprops with
>> every command that affects the repository. That way, a new revprop (e.g.
>> svn:user-agent) could be written every time. This would also have the
>> advantage that you could later check each revision and find out with
>> which client is was made. And of course it wouldn't be restricted to
>> Apache based repositories.
>
> Logging the useragent of every commit into a revprop?
>
> My initial reaction is "yuck!".
>
> What real use could this data be put to?
Think about a statistics page generated of a repository. Or do you think
that all those web statistics which show the browser (type and version)
with which the webpage was accessed are completely useless too?
Sure, it's not something that's very important, but surely 'nice to have'.
Also, revprops can be checked in a pre-commit hook.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Hi,
>
> A feature which is requested often on the TSVN mailing list is the
> ability to check the client version in a pre-commit hook.
> (the latest request was because they wanted to reject commits from TSVN
> clients which don't have the bugtraq features implemented yet)
For the non TSVN users here, could you explain what these features are?
Perhaps because I don't understand that, I can't see any reason to forbid a
client which can talk a compatible protocol from communicating with a
Subversion server.
> I've searched the mailing lists and found that this is already possible
> if the repository is hosted on an Apache server.
> (http://svn.haxx.se/dev/archive-2003-05/1680.shtml)
>
> Then I looked at the source where that agent string is set/sent:
> subversion/libsvn_ra_dav/session.c, line 659,660 (1.1.2 tag)
> ne_set_useragent(sess, "SVN/" SVN_VERSION);
> ne_set_useragent(sess2, "SVN/" SVN_VERSION);
>
> As it is now, another client can't change that string to something else
> (e.g. "TSVN/1.1.2"), so I'd like to request that this is changed into a
> define (which of course defaults to "SVN/"SVN_VERSION) but can be
> changed by a client when compiling/linking to the Subversion libs.
I don't think that a define can do that.
> Better would be a new function to set that string (usefull for those
> clients which use the precompiled language bindings).
A function could though.
I'm not sure if I agree that changing the UA is right though. It is the SVN
libraries which have control over the connection, not whichever client
happens to be telling the libraries what operations to perform.
> Even better would be if Subversion would allow to set revprops with
> every command that affects the repository. That way, a new revprop (e.g.
> svn:user-agent) could be written every time. This would also have the
> advantage that you could later check each revision and find out with
> which client is was made. And of course it wouldn't be restricted to
> Apache based repositories.
Logging the useragent of every commit into a revprop?
My initial reaction is "yuck!".
What real use could this data be put to?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
>
> On Jan 8, 2005, at 11:22 AM, SteveKing wrote:
>> A feature which is requested often on the TSVN mailing list is the
>> ability to check the client version in a pre-commit hook.
>> (the latest request was because they wanted to reject commits from
>> TSVN clients which don't have the bugtraq features implemented yet)
>>
>
> Hm, isn't considered bad design for clients and servers to accept/reject
> one another based solely on version number exchange?
Well, that depends. What about an administrator which wants to reject
clients because they have a lower version which has a security bug?
> I thought the "best practice" was for client and server to perform
> feature negotiation. For example, that's what the http OPTIONS request
> is all about. And I suspect that svnserve has something similar, no?
In this case, it's not about Subversion features but a TSVN feature. So
that OPTIONS request wouldn't help here much.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Request: make the user agent string a define
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 8, 2005, at 11:22 AM, SteveKing wrote:
> Hi,
>
> A feature which is requested often on the TSVN mailing list is the
> ability to check the client version in a pre-commit hook.
> (the latest request was because they wanted to reject commits from
> TSVN clients which don't have the bugtraq features implemented yet)
>
Hm, isn't considered bad design for clients and servers to
accept/reject one another based solely on version number exchange?
I thought the "best practice" was for client and server to perform
feature negotiation. For example, that's what the http OPTIONS request
is all about. And I suspect that svnserve has something similar, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org