[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Fri, 23 May 2008 08:03:43 +0300 (Jerusalem Daylight Time)

(moving to dev@)

neels_at_tigris.org wrote on Fri, 22 May 2008 at 22:04 -0000:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1796
> ------- Additional comments from neels_at_tigris.org Thu May 22 15:04:01 -0700 2008 -------
> Re: Daniel Shahaf, who said
> "...please try to come up with a recipe that doesn't
> require patching the client (especially in a way that makes it useless for
> normal operations)."
> This is quite difficult, because this fix-to-come essentially guards the server
> from *malicious* clients. To verify this, we actually need a malicious client.
> `svn' isn't malicious until the no-patch is applied.

According to my tests, 'svn' doesn't normalise log messages to CRLF now
(though it would be nice if it did), so 'svn ci -m "foo\r\nbar"' or svn
ci -F should do.

> Can you imagine a nice and easy way of doing this? All I can think of is
> netcatting recorded transaction data to svnserve... :P

(have you thought of writing a C test?)

> It's a real problem when trying to write a new test for this issue.

Until normalisation is implemented, see above. After normalisation is
implemented, test the normalisation. :)

> ------- Additional comments from neels_at_tigris.org Thu May 22 15:15:58 -0700 2008 -------
> Is there or may there ever be a revprop that is allowed to have CR ('\r') in its
> value?

(1) user-defined revprops (which are taken as opaque binary strings)
(2) Not sure; it might be allowed as 'whitespace' in svn:mime-type and
friends (unless they're internally normalized as well?)

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-23 07:04:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.