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

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/libsvn_delta/ subversion/tests/libsvn_subr/

From: Philip Martin <philip_at_codematters.co.uk>
Date: Wed, 26 Jul 2017 16:11:56 +0100

Stefan Sperling <stsp_at_elego.de> writes:

> Who will be blamed if, in the future, a package manager for some Linux/BSD
> system fixes an exploitable bug in lz4, and accidentally leaves some systems
> vulnerable because of a missing patch to SVN's internal copy?

Let us consider Subversion's embedded utf8proc. How well are we doing
from a security point of view?

In 2012 we imported upstream 1.1.5 and since then we have made various
minor fixes to the code but as far as I can tell we are still using that
1.1.5 code. Upstream has made several releases including one in 2016
with the ominous sounding change: "Buffer overrun fix". Is that change
relevant to our code? Can it be exploited in Subversion? Has anyone
ever checked? I've just had a quick look and our version of utf8proc is
so out-of-date it is hard to determine whether we are vulnerable or not.

Our use of utf8proc is mostly (completely?) confined to the client so if
there is an exploit it is probably not that interesting. The same can
not be said of the proposal to have the server use an embedded LZ4 to
decode untrusted network data.

-- 
Philip
Received on 2017-07-26 17:12:17 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.