Re: [Issue 1796] defective or malicious client can corrupt repository log messages

A number of weeks ago, there was a discussion on validation of the
commit log messages on their journey from client to server and back.

It was said, that:

Neels Janosch Hofmeyr wrote:
> So, right now, there is only *one* place where props get
> normalised/checked for consistence:
> - where the svn client receives a log message from the user
>
> The places, where checking the props is, supposedly, missing, are:
> - where the server receives props from a client out there.
> - where the server reads props from the repository file system.
> - where the svn client reads props from a server out there.

The first of the latter three has been fixed (issue 1796).
The last two are still lurking.

Since, I've had a discussion on the implications of fixing these latter
two, with stsp.

Imagine that someone has a repository containing log messages with CR or
non-UTF8 sequences. Then, *we* come along and make the server validate
log messages read from the file system, plus make the client validate
log messages received from the server. In effect, the user isn't able to
simply *look* at the log message anymore.

It struck us as a rather dumb situation, and I am since of the opinion
that the part of a log message's journey going in the direction towards
the user should not have prohibitive log message validation.

If everyone agrees, the question remains whether server and client
should print out a warning along with passing an inconsistent log
message towards the user.

What do you think?

-- 
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194