Dokuwiki: "Error while trying to use the following icon from the Manifest" in browser console

[mprins]

Seeing following error in the Javascript console of Chromium (Version 81.0.4044.138 (Official Build) (64-bit))

Error while trying to use the following icon from the Manifest: https://wild-water.nl/dokuwiki/_media/wiki/dokuwiki.svg (Download error or resource isn't a valid image)

when looking in the network tab I can see that the image is presented as a download:

Request URL: https://wild-water.nl/dokuwiki/_media/wiki/dokuwiki.svg
Request Method: GET
Status Code: 200 
Remote Address: 77.94.249.3:443
Referrer Policy: no-referrer-when-downgrade
accept-ranges: bytes
cache-control: private
content-disposition: attachment; filename="dokuwiki.svg";
content-length: 24200
content-type: application/octet-stream
date: Sat, 12 Sep 2020 11:47:33 GMT
etag: "72da88f8dc710fad0d80a674d00d35cc"
expires: Sun, 13 Sep 2020 11:47:33 GMT
last-modified: Sat, 12 Sep 2020 11:30:29 GMT
pragma: no-cache
server: Microsoft-IIS/10.0
status: 200
vary: Cookie
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: ASP.NET
x-xss-protection: 1; mode=block

Firefox 76 apparently does not request the manifest nor the image

It seems that SVG is not a known file extension in the DW mime config

[mprins]

seeing this happen on https://www.dokuwiki.org/dokuwiki too

[Klap-in]

This looks like that, if the mime type is unknown, then the media manager is strict in handling it. Even while we offer it our self i.e. it is already in the media manager.

I expect this file is offered via the mediamanager because it allows administrators easy uploading other icons. (but I guess that uploading a svg is default not allowed, because it is not permitted in the mime config.) @micgro42 did you try when developing this feature, to replace the image?

According to https://github.com/splitbrain/dokuwiki/issues/1045 we would not offer default svg support, due to lack of sanitizing options in DokuWiki. Svg-files could contain javascript.

[mprins]

the easy/safe fix is to replace the svg with a png then, such as lib/tpl/dokuwiki/images/logo.png

[Klap-in]

I guess all locations that are not via /_media/ url could work with svg. e.g. in the https://github.com/splitbrain/dokuwiki/tree/master/lib/images folder. Users can override all entries of the manifest and use any location, see https://www.dokuwiki.org/devel:manifest. But default it search the images in de media directory.

png looks as reasonable alternative indeed, but is of course no vector format.

[micgro42]

Mh, I looked into it a bit just now and I can reproduce it with a current Chrome version and both current code and with a git checkout back from when this code was created in 2018. Maybe the Chrome version from back then didn't complain?

Replacing it with a .png would remove much of the scaling efficiency of being able to use the same file for different sizes.

Moving the fallback to lib/images sounds a viable solution. OTOH, we might lose some caching-control that way? But I'm not sure if that is really important for a last-stage fallback image.

I haven't looked into it, but couldn't we add svg to mime.conf with a leading !? That seems like it would sufficiently address the security concerns related to included javascript. However, I feel like I'm missing some angle here, because otherwise, I would have expected to have been done already.

I looked only _very_ briefly into the options mentioned above, so some assumptions might be wrong. I'd be happy to fix this, but don't have much time right now. More input welcome :)

[michitux]

As written here, there is probably an easy fix for disallowing the execution of JavaScript in SVG uploads. If this is our only concern, we could then enable them by default and thus fix this issue.

[Klap-in]

1045 is solved, so this issue is solved as well?