problem with paths with spaces with 12.04 client with 14.04 server

[Stephane Chazelas]

source package: subversion
bin package: libapache2-mod-svn

The problem shows up with libapache2-mod-svn 1.8.8-1ubuntu3 on the current 14.04 (amd64 though that doesn't matter). It showed up in 1.7.14 already.

The problem is an interoperability problem with subversion clients prior to 1.7.x. Typically, ubuntu 12.04 clients (1.6.17) are affected by that bug. That means that anybody upgrading their server from 12.04 to 14.04 are potentially going to be affected (unless they upgrade their clients beforehand)..

There's a related bug with the subversion server coming with 13.10 which I'll raise shortly.

Newer clients (1.7 and above) are not affected even with "SVNAdvertiseV2Protocol Off" on the server (contrary to the 13.10 bug).

How to reproduce:

On a 14.04 server (as root),

apt-get install apache2 subversion libapache2-mod-svn
a2enmod dav_svn
svnadmin create /srv/svn
chown -R www-data: /srv/svn
cat > /etc/apache2/mods-available/dav_svn.conf << EOF
<Location /svn>
  DAV svn
  SVNPath /srv/svn
</Location>
EOF
service apache2 restart

On a 12.04 client:

svn co http://server/svn test
cd test
mkdir -p 'A B/C'
echo test > 'A B/C/x'
svn add 'A B'
svn ci -m m1
svn log 'A B/C/x'

That svn log command will fail with:

svn: Unable to parse URL '/svn/A B/C/x'

A commit of a change on that "x" file will fail as well:

echo test >> 'A B/C/x'
svn ci -m m2

When using svn log --config-option servers:global:neon-debug-mask=130 'A B/C/x'
we see:

Sending request headers:
PROPFIND /svn/A%20B/C/x HTTP/1.1
User-Agent: SVN/1.6.17 (r1128011) neon/0.29.6

(OK)

[status-line] < HTTP/1.1 207 Multi-Status
[<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns1="http://subversion.tigris.org/xmlns/dav/" xmlns:ns0="DAV:">
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://subversion.tigris.org/xmlns/dav/">
<D:href>/svn/A B/C/x</D:href>
<D:propstat>
<D:prop>
<lp1:version-controlled-configuration><D:href>/svn/!svn/vcc/default</D:href></lp1:version-controlled-configuration>
<lp1:resourcetype/>
<lp2:baseline-relative-path>A B/C/x</lp2:baseline-relative-path>
<lp2:repository-uuid>1e784bc0-1833-41df-a2eb-683d1610caa8</lp2:repository-uuid>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

While the problem with 13.10 (1.7.9) was too much URI encoding (space turned to %20 itself turned into %2520), it looks like in this case there's not enough encoding (href being /svn/A B/C/x instead of /svn/A%20B/C/x above).

It is really a bug because even < and > are not encoded. The reason why newer clients work is because they send different HTTP requests (OPTIONS, REPORT and no PROPFIND even with V2 disabled).

On 12.04, one can work around the problem by upgrading svn from the "svn" ppa (svn 1.7.9), but note that it breaks rapidsvn (segfault) and possibly other tools linking to libsvn.

As show above, space is not the only character causing problem.

[Stephane Chazelas (stephane-chazelas)]

No, it's not a duplicate. There's no proxy here, my bug affects the simplest deployment of subversion as long as 12.04 is used on the client and 14.04 on the server and spaces are used in file names in the repository

 It is a bug on the server, so in the newest version of subversion (1.8.8 released a few days ago)

And the symptoms are different. The double-encoding of space into %2520 is also found in the bug that I'm going to raise against 13.10, but not in this bug.

[Stephane Chazelas (stephane-chazelas)]

There's a problem with any DAV client, it's not only old svn client. So I'll raise the issue upstreams.

I had raised it here because in the past, similar reports to upstreams were answered with "then upgrade your client to fix the problem", while here it's a real concern for ubuntu.

But it is really a violation of the WebDAV protocol so I expect upstreams will want to fix it.

Exceirpt of traffic between cadaver and mod_dav_svn 1.8.8, see how some space and < and % characters are not escaped (but are in other contexts).

I suppose it's not impossible that there be security implications as someone may be able to craft a harmful PROPFIND response (since <, > are not encoded) by adding crafted file names to the repository.

  PROPFIND /svn/ HTTP/1.1
  User-Agent: cadaver/0.23.3 neon/0.29.1
  Connection: TE
  TE: trailers
  Host: vm189-eth0.vmnet60
  Depth: 1
  Content-Length: 288
  Content-Type: application/xml

  <?xml version="1.0" encoding="utf-8"?>
  <propfind xmlns="DAV:"><prop>
  <getcontentlength xmlns="DAV:"/>
  <getlastmodified xmlns="DAV:"/>
  <executable xmlns="http://apache.org/dav/props/"/>
  <resourcetype xmlns="DAV:"/>
  <checked-in xmlns="DAV:"/>
  <checked-out xmlns="DAV:"/>
  </prop></propfind>

  HTTP/1.1 207 Multi-Status
  Date: Wed, 26 Feb 2014 08:40:23 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Content-Length: 2549
  Content-Type: text/xml; charset="utf-8"

  <?xml version="1.0" encoding="utf-8"?>
  <D:multistatus xmlns:D="DAV:" xmlns:ns1="http://apache.org/dav/props/" xmlns:ns0="DAV:">
  <D:response xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:g0="DAV:" xmlns:g1="http://apache.org/dav/props/">
  <D:href>/svn/</D:href>
  <D:propstat>
  <D:prop>
  <lp1:getlastmodified>Tue, 25 Feb 2014 14:43:59 GMT</lp1:getlastmodified>
  <lp1:resourcetype><D:collection/></lp1:resourcetype>
  <lp1:checked-in><D:href>/svn/!svn/ver/5/</D:href></lp1:checked-in>
  </D:prop>
  <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
  <D:propstat>
  <D:prop>
  <g0:getcontentlength/>
  <g1:executable/>
  <g0:checked-out/>
  </D:prop>
  <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:propstat>
  </D:response>
  <D:response xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:g0="http://apache.org/dav/props/" xmlns:g1="DAV:">
⇨ <D:href>/svn/a>b</D:href>
  <D:propstat>
  <D:prop>
  <lp1:getcontentlength>10</lp1:getcontentlength>
  <lp1:getlastmodified>Tue, 25 Feb 2014 13:09:01 GMT</lp1:getlastmodified>
  <lp1:resourcetype/>
  <lp1:checked-in><D:href>/svn/!svn/ver/3/a%3Eb</D:href></lp1:checked-in>
  </D:prop>
  <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
  <D:propstat>
  <D:prop>
  <g0:executable/>
  <g1:checked-out/>
  </D:prop>
  <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:propstat>
  </D:response>
  <D:response xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:g0="DAV:" xmlns:g1="http://apache.org/dav/props/">
⇨ <D:href>/svn/A B/</D:href>
  <D:propstat>
  <D:prop>
  <lp1:getlastmodified>Tue, 25 Feb 2014 12:46:53 GMT</lp1:getlastmodified>
  <lp1:resourcetype><D:collection/></lp1:resourcetype>
  <lp1:checked-in><D:href>/svn/!svn/ver/1/A%20B</D:href></lp1:checked-i...

[Stephane Chazelas (stephane-chazelas)]

Possibly related: https://issues.apache.org/bugzilla/show_bug.cgi?id=55397

[Stephane Chazelas (stephane-chazelas)]

Yes, that was a change in API in apache at some point, dav_fs had to be modified for that https://svn.apache.org/viewvc?view=revision&revision=1531505

dav_svn wasn't modified, so the change in the apache API broke dav_svn basically.

dav_fs ships with apache2 so it's easy for it to align with the new API, but dav_svn doesn't.

That means that dav_svn will work properly with older apache, and it may be up to ubuntu to adapt to the new apache API since ubuntu ships now ships with a newer apache.

[Stephane Chazelas (stephane-chazelas)]

Sorry, replying to myself again and thinking aloud.

It looks like that change above https://svn.apache.org/viewvc?view=revision&revision=1531505 is what broke it, as we've got apache 2.4.7 on 14.04 now.

It sounds like the problem with double URI encoding has been "fixed" in both dav_svn and dav which means it now overshoots (no encoding instead of just one encoding).

[Stephane Chazelas (stephane-chazelas)]

Here's the related bug affecting 13.10 I mentioned earlier: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1285204

[Ben Reser (ben-chgtaa3qpp07)]

It is related to the httpd issue #55397 linked above. But it's not caused by r1531505 change but rather the r1529559 change (r1531505 only touches mod_dav_fs which has nothing to do with SVN).

I've opened an issue specifically on this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56480

My example case is slightly different than Stephane but it's all related.

For future reference, you're better off sending an email to the subversion lists rather than opening issues (svn prefers users not use our issue tracker to report issues and httpd's issue tracker is so busy we'll probably miss the issue) or leaving comments on old bugs (again for similar reasons).

I'm working to resolve this. In the meantime there's really no workaround or fix available

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[John Pye (jdpipe)]

This bug is resolved by modifying a new 14.04 server to install the apache2 packages from https://launchpad.net/~ondrej/+archive/ubuntu/php5, ie

sudo apt-add-repository ppa:ondrej/php5
sudo apt-get update
sudo apt-get dist-upgrade

Worked for me... the new Apache2 packages should be urgently included in Ubuntu 14.04 LTS, since users upgrading their Subversion servers will inevitably have horrible problems.

[Stephane Chazelas (stephane-chazelas)]

The bug is in apache2. It has been fixed upstreams in 2.4.10 and a patch is available at https://bz.apache.org/bugzilla/attachment.cgi?id=31705

[David Buckley (dbuckley-k)]

Is there a timeframe for this fix being included in 14.04?

I was able to work around it by recompiling apache with the referenced patch, but it would be great to have fixed in the official packages.

[Andreas Hasenack (ahasenack)]

The linked upstream apache2 bugs are fixed since 2.4.7 and 2.4.10, and these are available in currently supported Ubuntu releases. Ubuntu Trusty 14.04 has 2.4.10 available in trusty-backports.

Therefore, I'll mark this bug as fix released. Thanks.