Crashes in subversion with unexpected targets

[sebb]

I've seen some crashes in SVN where the target does not have the expected type.

For example:

$ svn info https://www.apache.org/foundation/records/990-2016.pdf
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
line 96: assertion failed
(svn_uri__is_ancestor(pathrev->repos_root_url, url))
Aborted (core dumped)

$ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt
Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt':
svn:eol-style
native

$ svn ps svn:mime-type text/plain
https://dist.apache.org/repos/dist/dev/whimsy/test.txt
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c'
line 1634: assertion failed (! svn_path_is_url(relative))
Aborted (core dumped)

$ svn --version
svn, version 1.13.0 (r1867053)
compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu

Whilst these are invalid usages, I don't believe they should crash
with an assertion.

Do I need to raise bugs for these? Or are they already known?

Sebb

[Pavel Lyalyakin via users]

On Wed, Apr 19, 2023 at 12:44 PM sebb <seb...@gmail.com> wrote:

I've seen some crashes in SVN where the target does not have the expected type.

For example:

$ svn info https://www.apache.org/foundation/records/990-2016.pdf
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
line 96: assertion failed
(svn_uri__is_ancestor(pathrev->repos_root_url, url))
Aborted (core dumped)

I can confirm that the problem reproduces with SVN 1.14.2.

Although the reproduction script is different, this seems to be the same assert I reported some time ago in the dev@ mailing list (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw).

 

$ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt
Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt':
  svn:eol-style
    native

$ svn ps svn:mime-type text/plain
https://dist.apache.org/repos/dist/dev/whimsy/test.txt
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c'
line 1634: assertion failed (! svn_path_is_url(relative))
Aborted (core dumped)

$ svn --version
svn, version 1.13.0 (r1867053)
   compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu

Whilst these are invalid usages, I don't believe they should crash
with an assertion.

Do I need to raise bugs for these? Or are they already known?

Sebb

--

With best regards,
Pavel Lyalyakin
VisualSVN Team

[Daniel Sahlberg]

Den ons 19 apr. 2023 kl 11:44 skrev sebb <seb...@gmail.com>:

I've seen some crashes in SVN where the target does not have the expected type.

Both asserts also on a recent trunk build, so at least it isn't resolved yet.

 

For example:

$ svn info https://www.apache.org/foundation/records/990-2016.pdf
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
line 96: assertion failed
(svn_uri__is_ancestor(pathrev->repos_root_url, url))
Aborted (core dumped)

The same assert has been reported previously (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although with a different use case.

From what I can see in GDB, Subversion seems to be able to open a WebDAV session with www.apache.org. It asks for the DAV:version-controlled-configuration which seems to return https://www.apache.org/repos/asf. Now, since https://www.apache.org/foundation/records/ is not a child of https://www.apache.org/repos/asf it triggers an assert.

Is it correct that https://www.apache.org/foundation/records/ responds to WebDAV commands, and why does it reply with https://www.apache.org/repos/asf?

I'm leaning towards an incorrect server configuration.

$ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt
Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt':
  svn:eol-style
    native

$ svn ps svn:mime-type text/plain
https://dist.apache.org/repos/dist/dev/whimsy/test.txt
svn: E235000: In file
'/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c'
line 1634: assertion failed (! svn_path_is_url(relative))
Aborted (core dumped)

Setting a versioned property on a URL is not supported if I'm reading the SVN Book correctly (https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.c.propset). It is obviously wrong to hit an assertion, there should be an error message instead if trying to operate on a URL. I did a very quick sketch and it seems easy enough (a few lines of code in propset-cmd.c), but it is getting too late to get it into style and run all testcases tonight.

Feel free to add this as an issue in JIRA.

For the record, if someone else sees this thread. svnmucc should be the correct tool in this case, it will create a new revision adding the versioned property to the URL target.

Kind regards,

Daniel

[sebb]

On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg
<daniel.l...@gmail.com> wrote:
>
> Den ons 19 apr. 2023 kl 11:44 skrev sebb <seb...@gmail.com>:
>>
>> I've seen some crashes in SVN where the target does not have the expected type.
>
>
> Both asserts also on a recent trunk build, so at least it isn't resolved yet.
>
>>
>>
>> For example:
>>
>> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
>> svn: E235000: In file
>> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
>> line 96: assertion failed
>> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
>> Aborted (core dumped)
>
>
> The same assert has been reported previously (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although with a different use case.
>
> From what I can see in GDB, Subversion seems to be able to open a WebDAV session with www.apache.org. It asks for the DAV:version-controlled-configuration which seems to return https://www.apache.org/repos/asf. Now, since https://www.apache.org/foundation/records/ is not a child of https://www.apache.org/repos/asf it triggers an assert.
>
> Is it correct that https://www.apache.org/foundation/records/ responds to WebDAV commands, and why does it reply with https://www.apache.org/repos/asf?

No idea. The redirect works fine for the main purpose which is
displaying a PDF file from SVN.

> I'm leaning towards an incorrect server configuration.

Maybe, but the point is that svn should not crash.

>> $ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt
>> Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt':
>> svn:eol-style
>> native
>>
>> $ svn ps svn:mime-type text/plain
>> https://dist.apache.org/repos/dist/dev/whimsy/test.txt
>> svn: E235000: In file
>> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c'
>> line 1634: assertion failed (! svn_path_is_url(relative))
>> Aborted (core dumped)
>
>
> Setting a versioned property on a URL is not supported if I'm reading the SVN Book correctly (https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.c.propset). It is obviously wrong to hit an assertion, there should be an error message instead if trying to operate on a URL.

Exactly.

> I did a very quick sketch and it seems easy enough (a few lines of code in propset-cmd.c), but it is getting too late to get it into style and run all testcases tonight.

It would be nice if it did work, but at least it should not crash.

> Feel free to add this as an issue in JIRA.

Thanks.

[Daniel Sahlberg]

Den tors 20 apr. 2023 kl 01:22 skrev sebb <seb...@gmail.com>:

On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg
<daniel.l...@gmail.com> wrote:
>
> Den ons 19 apr. 2023 kl 11:44 skrev sebb <seb...@gmail.com>:
>>
>> I've seen some crashes in SVN where the target does not have the expected type.
>
>
> Both asserts also on a recent trunk build, so at least it isn't resolved yet.
>
>>
>>
>> For example:
>>
>> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
>> svn: E235000: In file
>> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
>> line 96: assertion failed
>> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
>> Aborted (core dumped)
>
>
> The same assert has been reported previously (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although with a different use case.
>
> From what I can see in GDB, Subversion seems to be able to open a WebDAV session with www.apache.org. It asks for the DAV:version-controlled-configuration which seems to return https://www.apache.org/repos/asf. Now, since https://www.apache.org/foundation/records/ is not a child of https://www.apache.org/repos/asf it triggers an assert.
>
> Is it correct that https://www.apache.org/foundation/records/ responds to WebDAV commands, and why does it reply with https://www.apache.org/repos/asf?

No idea. The redirect works fine for the main purpose which is
displaying a PDF file from SVN.

Which redirect? Subversion handles a 301/302 redirect just fine. The headers looks like a file served directly from the web server. (Maybe there is a behind-the-scenes redirect somehow that doesn't show here, but then should the server really reply to DAV requests?

[[[

C:\Users\dsg>curl -I https://www.apache.org/foundation/records/990-2016.pdf

HTTP/1.1 200 OK

Connection: keep-alive

Content-Length: 329732

Server: Apache

Last-Modified: Sat, 15 Apr 2023 10:22:29 GMT

ETag: "1909150//infrastructure/site/trunk/content/foundation/records/990-2016.pdf"

Cache-Control: max-age=604800, max-age=3600

Content-Type: application/pdf

Via: 1.1 www.apache.org, 1.1 varnish, 1.1 varnish

Expires: Mon, 17 Apr 2023 13:30:44 GMT

Content-Security-Policy: default-src 'self' 'unsafe-inline' https://www.apachecon.com/ https://www.google.com/cse/ https://cse.google.com/ https://www.googleapis.com/generate_204 http://*.google.com/generate_204 https://afs.googlesyndication.com/ https://csp.withgoogle.com/ https://www.google.com/images/ https://ssl.gstatic.com/ui/ https://docs.google.com/forms/ https://www.youtube.com/embed/; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cse.google.com/ http://cse.google.com/adsense/search/async-ads.js https://www.google.com/cse/ https://partner.googleadservices.com/; style-src 'self' 'unsafe-inline' https://www.google.com/cse/; frame-ancestors 'none';

Strict-Transport-Security: max-age=31536000; preload

Accept-Ranges: bytes

Date: Thu, 20 Apr 2023 06:01:27 GMT

Age: 0

X-Served-By: cache-hel1410029-HEL, cache-bma1680-BMA

X-Cache: HIT, HIT

X-Cache-Hits: 1, 1

X-Timer: S1681970487.818068,VS0,VE377

Vary: Accept-Encoding

]]]

Kind regards,

Daniel

[sebb]

On Thu, 20 Apr 2023 at 07:10, Daniel Sahlberg

<daniel.l...@gmail.com> wrote:
>
> Den tors 20 apr. 2023 kl 01:22 skrev sebb <seb...@gmail.com>:
>>
>> On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg
>> <daniel.l...@gmail.com> wrote:
>> >
>> > Den ons 19 apr. 2023 kl 11:44 skrev sebb <seb...@gmail.com>:
>> >>
>> >> I've seen some crashes in SVN where the target does not have the expected type.
>> >
>> >
>> > Both asserts also on a recent trunk build, so at least it isn't resolved yet.
>> >
>> >>
>> >>
>> >> For example:
>> >>
>> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
>> >> svn: E235000: In file
>> >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
>> >> line 96: assertion failed
>> >> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
>> >> Aborted (core dumped)
>> >
>> >
>> > The same assert has been reported previously (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although with a different use case.
>> >
>> > From what I can see in GDB, Subversion seems to be able to open a WebDAV session with www.apache.org. It asks for the DAV:version-controlled-configuration which seems to return https://www.apache.org/repos/asf. Now, since https://www.apache.org/foundation/records/ is not a child of https://www.apache.org/repos/asf it triggers an assert.
>> >
>> > Is it correct that https://www.apache.org/foundation/records/ responds to WebDAV commands, and why does it reply with https://www.apache.org/repos/asf?
>>
>> No idea. The redirect works fine for the main purpose which is
>> displaying a PDF file from SVN.
>
>
> Which redirect?

Actually it is a rewrite:

https://github.com/apache/www-site/blob/main/content/foundation/records/.htaccess

[sebb]

On Fri, 21 Apr 2023 at 18:00, sebb <seb...@gmail.com> wrote:
>
> On Thu, 20 Apr 2023 at 07:10, Daniel Sahlberg
> <daniel.l...@gmail.com> wrote:
> >
> > Den tors 20 apr. 2023 kl 01:22 skrev sebb <seb...@gmail.com>:
> >>
> >> On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg
> >> <daniel.l...@gmail.com> wrote:
> >> >
> >> > Den ons 19 apr. 2023 kl 11:44 skrev sebb <seb...@gmail.com>:
> >> >>
> >> >> I've seen some crashes in SVN where the target does not have the expected type.
> >> >
> >> >
> >> > Both asserts also on a recent trunk build, so at least it isn't resolved yet.
> >> >
> >> >>
> >> >>
> >> >> For example:
> >> >>
> >> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
> >> >> svn: E235000: In file
> >> >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
> >> >> line 96: assertion failed
> >> >> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
> >> >> Aborted (core dumped)
> >> >
> >> >
> >> > The same assert has been reported previously (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although with a different use case.
> >> >
> >> > From what I can see in GDB, Subversion seems to be able to open a WebDAV session with www.apache.org. It asks for the DAV:version-controlled-configuration which seems to return https://www.apache.org/repos/asf. Now, since https://www.apache.org/foundation/records/ is not a child of https://www.apache.org/repos/asf it triggers an assert.
> >> >
> >> > Is it correct that https://www.apache.org/foundation/records/ responds to WebDAV commands, and why does it reply with https://www.apache.org/repos/asf?
> >>
> >> No idea. The redirect works fine for the main purpose which is
> >> displaying a PDF file from SVN.
> >
> >
> > Which redirect?
>
> Actually it is a rewrite:
>
> https://github.com/apache/www-site/blob/main/content/foundation/records/.htaccess

There is no indication on the index page that the PDF file is served
from SVN so it does not matter that SVN access is not supported.

But of course it should fail gracefully.