subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <>
Subject 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/
Date Wed, 26 Jul 2017 15:11:56 GMT
Stefan Sperling <> 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.


View raw message