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
Received on Sat Jan 8 20:44:28 2005