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
> How can a bug in the client harm the server?
Very simple. Just have a look at all the svn_client_* functions. Example:
"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
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
> 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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jan 8 20:44:28 2005