ping @PhilETaylor

Not sure why you have tagged me :-) I cannot merge anything :-(

Discussed several Times, Example: #18373

@mbabker at #18373

Long and short though is because of the nature of SVG files there are additional security precautions that have to be taken to safely allow those files to be uploaded/used and that's why the support is not there at this time.

So i'm closing this PR.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20741

Phile I tagged you because of me security concerns regarding svg support.

I'm not suggesting a discussion, but a solution. All previous discussions lead to only one conclusion: "and let's ban PHP - it's so unsafe for Joomla", and while you're talking, I'm doing my job and sharing it with you. Maybe stop turning on the paranoid mode and finally give people what other systems have long been working for more than one year? Or let's ban life - it has so many security problems.

@wojsmol best to always tag @joomla/security which is a group tag :) I'm a pawn in an otherwise great team.

@AlekVolsk There is nothing stopping you allowing SVG on your own sites if you understand the security implications, mitigate them, and dont allow users to upload SVG's.

However, Joomla is a mass market solution and as such has to cater for a wide range of users, from those that cannot even spell Joomla, to those at the other end of the scale as well as a myriad of server configurations (and mis-configuration). As such, we have to draw the line for security somewhere, and SVG unfiltered upload is one side of the line, for very very good reasons which have been repeatedly discussed to death, not only in Joomla, but in other projects too.

You could add this at least as a disabled option, with the output of a warning about possible (I emphasize - only possible, but no more) security problems when it is enabled (here is a link to the relevant document describing the problem). Joomla today - the only mass cms without svg support.

However, as want. You are so intimidated by your own problems that you will never dare to step over them. If you are not able to write a security check of the file when it is uploaded to the server - then it should not be a problem for the end user, and the problem of incorrect server configurations - this is clearly not a Joomla problem, do not interfere with the warm soft.

Well you continue to abuse the project all you want. Its clear you do not have a full understanding of the underlying issue or the magnitude of your comments or demands.

Joomla today - the only mass cms without svg support

Factually incorrect.

Wordpress:
https://bjornjohansen.no/svg-in-wordpress

Drupal:
https://www.thirdandgrove.com/svg-images-drupal-8

here are 2 theoretical solutions:

1. when loading an svg file, parse it for the presence of tags and js-attributes prohibited in it

2. add support for an attribute to the media field that specifies the allowed file types or mime-types (if a specific field does not have an attribute, take a standard set or an allowed set of com-media parameters)

the problem is not in the format or security, and the reluctance to solve the issue

Well I'll bow out not. Its clear you don't have a full grasp of the issue, so I'll not comment further. If the real solution was so easy for mass market open source software then it would have already been done in all apps - including Joomla. The fact is, its not as easy as you like to make out. Over and out.

1. If that could be done then the world would have done it
2. Dont we already have that in the options for the media managr

when loading an svg file, parse it for the presence of tags and js-attributes prohibited in it

As pointed out in the links above, a blacklist-approach will never be the bullet proof solution that it has to be. There are just way to many attack vectors and with the ongoing changes in the technology we’ll see additional vectors coming up constantly. It’s exactly the same issue we have we the blacklist-approach in the HTML filter, causing XSS-issues in almost every recent release.

The only feasible way would be a whitelist-approach, that however is rather complex and will massively limit the usecases of SVG support.

Again, some excuses. Let's not go on, you're not going to do anything.

This #13499 might be interesting (by disallowing js and css urls)

will massively limit the usecases of SVG support.

@SniperSister I think supporting only the vector part (path etc) is sufficient for common users/common usage. Devs can upload whatever they want one way or another to their servers...

You know what the saddest thing is? You didn't even try to figure out what I was offering you. I do not need to upload svg to the server - i will do it via ftp. All i want to do is just select a previously uploaded file in the media field that is already present on the server.

The media field does not download files - it just selects an existing file. I just want to be able to stupidly select a file, nothing more.

I really do not understand your stubbornness where there is no problem. You just deny everything inconvenient to you, just because, probably on the general wave of denials, without going into details; unwillingness to leave a comfort zone to bypass the barrier preventing the increase of comfort level in general.

Sorry for my clumsy english, but I really don't understand your motives.