Gitea can't render SVG files.

[lcges]

Hello!

Gitea can't render SVG files.
It is a matter of settings?
or
Do not implement functionality?

GITEA:

GITHUB:

[pgaskin]

The problem is serving with the wrong mime type.

[arkraft]

Right now the mime type is read by calling http.DetectContentType. This does not support the "image/svg+xml" mime type. There was a feature request for this (golang/go#15888), but it seems they won't implement it until it is also implemented in the mimesniff spec (whatwg/mimesniff#7). mime.TypeByExtension supports "image/svg+xml" as it has ".svg" in its built-in table. https://github.com/golang/go/blob/release-branch.go1.6/src/mime/type.go#L35

[lunny]

fileType := mime.TypeByExtension(path.Ext(filePath))
if fileType == "" {
    fileType = http.DetectContentType(buffer)
}

It seems change the code to this will fix the bug.

[pgaskin]

My render raw files pull request does exactly this, but tboerger seems to think it is a very big security risk.

[lcges]

Hi, this is text about SVG security. Don't worry, GitHub could do it, so can we!

First make sure that we set a good headers safety. The basic HTTP response headers with the SVG file will be:

• Content-Type: image / svg + xml,
• X-Content-Type-Options: nosniff.

In addition, the magazine SVG files could be transferred to a separate domain or subdomain that does not require authentication even through mechanisms such as cookies (files can be referenced eg. The GUID, you should also add .svg extension to file names). In such a situation, a successful XSS attack will be much less of a threat.

Then, set up a very strict policy Content Security Policy (CSP) - whether it is for a script that returns the content of vector graphics, or the server that serves SVG files from the directory. Setting the CSP value such as Content-Security-Policy: script-src 'none' turns off the ability to execute scripts for the document (ie malicious graphics, SVG).

SVG files can also be processed on the server and convert to safer raster image formats (eg. PNG). You can also attempt to remove potentially dangerous scripts - for this purpose can be used, eg. Utility SVG Purifier.

As you can see ideas to deal with SVG format is quite a lot, but by far the best option is to use SVG files only by developers and the strict prohibition upload such documents.

Say NO SVG files from an untrusted source.

[lcges]

Is there any plans to add support for SVG in the near future?

[lunny]

No people are working on this.

[edgar-bonet]

I have reported the issue to the Gogs bug tracker, before even knowing about Gitea.

[edgar-bonet]

I tried to investigate the issue. I have no solution, but some info that I hope will be helpful:

SVG embedded in markdown

SVG images do not display in rendered markdown. The following

![alt text](image.svg)

is rendered as

<a href="/USER/REPO/raw/master/image.svg" rel="nofollow"><img
src="/USER/REPO/raw/master/image.svg" alt="alt text"></a>

by both Gogs and Gitea. GitHub's rendering is only slightly different: it links to the blob instead of the raw page, it has target="_blank" instead of rel="nofollow", and it adds style="max-width:100%;" to the img tag. The image, however, is not rendered by the browser (Firefox and Chromium at least) because it is served with the HTTP header

Content-Type: text/plain; charset=utf-8

This is consistent between the three services tested. See my test repo:

• hosted on github.com
• mirrored on try.gogs.io
• mirrored on try.gitea.io

SVGs served by GitHub

GitHub has a feature lacking in both Gogs and Gitea: the blob page has buttons for switching between “source blob” and “rendered blob” views, defaulting to the latter. This can be useful since, as stated above, the raw page does not render the image in-browser.

The implementation, however, seems quite complex. The “rendered blob” view uses an iframe pointing to render.githubusercontent.com. This iframe uses JavaScript to generate an img element with a data URL containing the image. Any JavaScript embedded in the SVG is not stripped, but the browser does not interpret it anyway.

When serving SVG from raw URLs, GitHub issues a 302 redirect to raw.githubusercontent.com. Following the redirect, the SVG is served with what looks like a lot of security-related headers:

Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
Content-Type: text/plain; charset=utf-8

Embedding SVGs containing JavaScript

Testing with my local Web server, I found that neither Firefox nor Chromium would interpret JavaScript embedded in an SVG if that SVG is loaded from an HTML's img element. This could be what makes GitHub's “rendered blob” safe. The JavaScript is however interpreted if the HTML embeds the SVG using an iframe, an embed or an object element.

[bkcsoft]

Gitea (and Gogs) does not handle multiple domains, which would be a requirement for this. This has been discussed some over at gogs/gogs#1314 . And there's already ?render=1 gogs/gogs#2593 that could be used for this if you really want to. As for adding an option to always do this, the answer is currently 'no' since it's a security risk #683

[edgar-bonet]

Don't the headers

Content-Security-Policy: default-src 'none'
X-XSS-Protection: 1; mode=block

provide a reasonable level of protection against these security risks?

[jonasob]

It seems ?render=1 doesn't do much, and I even wonder if what I'm trying to do would be solved by this! Here's what I'm trying to do. I have an svg file, which is served by Gitea under

https://git.fsfe.org/reuse/reuse-ci/raw/master/reuse-compliant.svg

I would like to include this in a README.md as such:

[![reuse compliant](https://git.fsfe.org/reuse/reuse-ci/raw/master/reuse-compliant.svg)](https://git.fsfe.org/fsfe/reuse-web) 

Adding ?render=1 doesn't seem to do much of a difference here. I could, and probably will need to, host the svg on a standard website, but it seems silly to spin up a webserver when it's already (in theory) served through Gitea :)