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
Received on Sat Jan 8 22:46:51 2005